IRC channel logs
2023-07-10.log
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>the PR is too outdated to be useful, but I’ll try to wrap the panmirror.js in boilerplate for UMD <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 😕 <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>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"; … <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>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>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.