IRC channel logs


back to list of logs

<rekado>the problem with rstudio is that panmirror is expected to be in umd format, but esbuild only does iife
<rekado>it’s not a huge difference
<rekado>there’s a PR for esbuild that has been approved but never got merged:
<rekado>the PR is too outdated to be useful, but I’ll try to wrap the panmirror.js in boilerplate for UMD
<PurpleSym>Hm, what’s the difference?
<rekado>honestly, when you strip away all the stuff that’s only needed when running with node… I don’t see any.
<rekado>as a sanity check I took the working panmirror.js from our docker installation and it works fine.
<rekado>so now I’m using esbuild’s banner and footer to wrap the esm output in a minimal umd-like function call
<PurpleSym>I saw that vite builds UMD, but didn’t think it would make a difference 😕
<PurpleSym>(As long as the variables are in place.)
<rekado>I’m not trusting my ability to strip away the non-essential
<PurpleSym>Can you put that panmirror.js from the Docker image somewhere?
<rekado>it’s minified
<PurpleSym>And what’s that UMD boilerplate you’re talking about? One of these?
<rekado>what you can see, though, is that there’s a UMD “header”
<rekado>this is the header: (function(ki,Nt){typeof exports=="object"&&typeof module<"u"?module.exports=Nt():typeof define=="function"&&define.amd?define(Nt):(ki=typeof globalThis<"u"?globalThis:ki||self,ki.Panmirror=Nt
<rekado>())})(this,function(){"use strict"; …
<PurpleSym>Ah, right, after the vite CSS stuff.
<rekado>in the browser it seems to boil down to (function (ki, Nt) { ki.Panmirror=Nt() })(this, thunk)
<rekado>i.e. this.Panmirror=function() { … return { Editor: …, UI…}}
<rekado>I can’t tell if that’s any different from what you did by defining _internalPanmirror and then setting window.Panmirror = _internalPanmirror
<rekado>other than the fact that it’s using “this”
<rekado>(I never know what “this” really is)
<PurpleSym>this depends on the context that is running the script. So it can be something else than window.
<PurpleSym>Perhaps it’ll work if we just use this instead of window?
<rekado>would be nice if we could easily override the source of panmirror.js without a rebuild (and without modifying files in /gnu/store)
<PurpleSym>You could run a local nginx, proxy RStudio and rewrite that particular URL. 😅
<PurpleSym>I can also just rebuild it with this. Shouldn’t take too long.
<rekado>my attempts just brought me right back to the error popup, which is due to the fact that “this$static.editor_ is null” ¯\_(ツ)_/¯
<PurpleSym>Yeah, I guess it would border on insanity to expect a different outcome on my end then.
<PurpleSym>Have you tried adding the UMD boilerplate yet?
<PurpleSym>It also looks like this in the context of panmirror.js is just window, so…
<rekado>I’m trying to narrow in on the location of the error.
<rekado>looks like it’s a problem with the initialization of editor plugins
<rekado>it initializes pluginplugin$ twice
<rekado>fixed it by uniquifying the list of plugins
<rekado>(in the generated panmirror.js…)
<rekado>the source file for that would be /gnu/store/8zspa0l0gmgwqi20px6g9xj8ry7c17ml-node-prosemirror-state-1.4.3/lib/node_modules/prosemirror-state/dist/index.cjs
<rekado>sorry, that’s an output
<rekado>the source file would be
<rekado>I haven’t figured out yet where the list of plugins is passed to the configuration
<PurpleSym>Looking at the call stack I see the constructor of Editor and then EditorState.create.
<PurpleSym>There’s indeed multiple plugins called plugin$
<PurpleSym>Namely Plugin4, Plugin, Plugin22 and possibly more.
<PurpleSym>So, it seems that esbuild includes multiple copies of prosemirror-state, which all carry their own stateful createKey. That function is supposed to generate a unique plugin name.
<PurpleSym>But since those createKey[2–7] do not share their state, the plugins end up being called plugin$ only.
<PurpleSym>We’d have to change node-build-system to symlink dependencies into node_modules I think.
<PurpleSym>Hoping esbuild recognizes the files are the same and includes them only once…
<rekado>I patched all the createKey.?("plugin") calls with a global call to guix_createKey
<rekado>this fixes the immediate problem, but in the visual editor hitting the return key leads to another backtrace…
<rekado>“Can not convert <> to a Fragment (looks like multiple versions of prosemirror-model were loaded)”
<rekado>only happens on the first line for me. Everything else works.
<PurpleSym>Yeah, I’m counting 10 inclusions of prosemirror-model.
<PurpleSym>Same for prosemirror-transform.
<PurpleSym>As a really dumb workaround we could also vendor all JavaScript dependencies and build our own node_modules directory…
<rekado>can we do this with “npm install --offline --install-links=true”?
<rekado>oh, that’s the configure phase of node-build-system, which has been deleted in js-panmirror
<rekado>I used union-build to generate a single node_modules directory and set NODE_PATH to it, but it had no impact on the generated createKey.* procedures
<PurpleSym>So the esbuild still pulls in node_modules subdirectories from dependencies, not the node_modules directory you built? You can check by grepping panmirror.js for '//'.
<rekado>I changed the union-build invocation so that it doesn’t symlink but copies. Now it’s actually using the stuff in node_modules
<rekado>but it also complains now where it didn’t complain before
<rekado>e.g. in node_modules/react-textarea-autosize/package.json it says that for import it needs dist/react-textarea-autosize.browser.cjs.mjs, but we only have dist/react-textarea-autosize.browser.cjs.js
<rekado>I’ll patch this now, but I guess there will be more such problems
<rekado>patched that and it built fine, but I still get “looks like multiple versions of posemirror-model were loaded”
<rekado>and the same independent createKey* variants are created
<rekado>I’m okay with shipping it with a rough patch to replace createKey.?("plugin") with a call to a global function
<rekado>I’d rather have the plot plane fixed than keep messing with the visual editor.