[Bug] v0.51.0 breaks for browser based imports

[tobiu]

Reproducible in vscode.dev or in VS Code Desktop?

• Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

• Not reproducible in the monaco editor playground

Monaco Editor Playground Link

No response

Monaco Editor Playground Code

No response

Reproduction Steps

upgrade from v0.50.0 to v0.51.0

Actual (Problematic) Behavior

v0.50.0 was including the script: editor/editor.main.nls.js.

this silently got removed in v0.51.0 without getting mentioned inside the release log:
e52ff42

after removing the script as well inside the Neo.mjs env, i encountered several errors and warnings:

Expected Behavior

there should be no undocumented breaking changes in minor versions.

Additional Context

cross-reference ticket:
neomjs/neo#5822

[hediet]

This is because the blob context cannot load relative urls.
@bpasero as discussed, we should probably make these URLs absolute.

[tobiu]

i looked a bit more into it. using v0.50.0:

i assume the monaco worker name is "javascript". we do not see the neo workers here, since we are inside the shared workers mode of the framework.

what definitely changed with v0.51.0 is that monaco is trying to use importScripts. now this is a problem, since we are inside a JS module scope. in this context, monaco should stick to use import, since importScripts can not work.

makes sense?

off topic:
we have the multi-window support (without a native shell) fully working inside the Neo.mjs framework. so we can move the preview mode (mounting the widgets which get described inside the monaco editor) into different browser windows. we could also move multiple monaco editor instances into multiple windows, and they can still communicate. if it is a backlog item for you to also support multi-window, we can connect. you could save a lot of time with looking into the neo source code (MIT licensed).

[bpasero]

Potential fix: microsoft/vscode@634933e

[tobiu]

I just tried it out in my use-case with v0.52.0. Not sure if the hotfix-candidate was already in there.

If so, it did not work:

As mentioned inside my last comment: I really think the main issue is that importScripts() can not work inside a JavaScript module based setting. So we need dynamic imports => import() instead for this context. I recommend to take a closer look into your isESM check, since it is already there, just not hitting true.

You are welcome to ping me, in case you need help. We could do a quick screen-sharing session to enable you to run my use-case locally.

[MaxenceMouchard]

Same error using monaco-editor-webpack-plugin 7.1.0 under monaco 0.52.0
@aiday-mar The task goes into the backlog? How are we supposed to handle this? I don't use any overrides about worker or url's, for my purposes, this is a blocker bug.

[JMGomes]

Same Issue here. I'm blocked from use the latest versions due to this.

[IMax153]

We in the Effect-TS org have also started experimenting with re-writing our playground (which leverages Monaco) to be bundled with Vite instead of dynamically loaded from a CDN.

While we are able to successfully run our playground, the issue that @tobiu described in great detail with import vs importScripts is blocking us from being able to register a custom TS worker with Monaco client side.

[GKersten]

@aiday-mar I notice this issue did move to the backlog, we had to downgrade to Monaco v0.50 to prevent this error in the meantime. Is there any way to prevent this error or suggested work around to allow for an upgrade?

[arnoudkooi]

I feel this issue is also related to the issue I am facing when trying to upgrade from 0.43.0 to 0.52.0 in my browser extension.
I get errors like below, not exactly sure, but could it be Manifest v3 does not allow loading script with the workerMain.js#javascript syntax. Trying to modify the content security policy does not work, as that does not allow loosening the setting like object-src 'self';

Refused to load the script 'chrome-extension://iimpebfldpbfipbodemijjbfblmkhoeh/js/monaco/vs/base/worker/workerMain.js#javascript' because it violates the following Content Security Policy directive: "script-src 'self' 'wasm-unsafe-eval' 'inline-speculation-rules' ". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback

And

Refused to load the script 'chrome-extension://iimpebfldpbfipbodemijjbfblmkhoeh/js/monaco/vs/base/worker/workerMain.js#javascript' because it violates the following Content Security Policy directive: "script-src 'self' 'wasm-unsafe-eval' 'inline-speculation-rules' http://localhost:* http://127.0.0.1:*". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

[straakaa]

Hello,
any update? I also can't upgrade to latest.

[x-etienne]

Same problem with 0.52.0

[MaxenceMouchard]

I would add that your Monaco Editor playground is also affected by this bug ...
https://microsoft.github.io/monaco-editor/playground.html?source=v0.52.0#example-creating-the-editor-hello-world