Runtime warning about "Could not create web worker(s)..."

[jhk-mjolner]

Full warnings I get are

Could not create web worker(s). Falling back to loading web worker code in main thread, which might cause UI freezes. Please see https://github.com/microsoft/monaco-editor#faq

I don't think I'm getting the UI freezes it mentions, but the warning appeared when I changed from using the buildWorkerDefinition() method from the monaco-editor-workers package to using the new useWorkerFactory method of building/initializing workers. Or it could be from updating the monaco-languageclient packages, I'm not sure, but I don't think I can use monaco-editor-workers with the newer monaco-languageclient packages.
I'm using the monaco-editor-wrapper, but the warnings also appear in a branch I have where I'm not using the wrapper, so it doesn't appear to be related to that.

It seems to be only about the simpleWorker, and it happens even if I don't include the 'TextEditorWorker' and 'TextMateWorker' functions under workerLoaders for the useWorkerFactory() call like it is here

I'm using Angular and Webpack, and these versions of monaco packages:
monaco-editor: 0.52.2,
monaco-editor-wrapper: 6.2.5
monaco-languageclient: 9.2.5

A bit more from the console log in case it's relevant:

My code where I'm using monaco editor can be seen here

I'll reiterate that I'm not seeing errors or anything breaking that I'm aware of, but I'm guessing it's not intended.

[cdietrich]

Had this too. Once I changed the useWorkerFactory to use module paths that can be resolved, it worked for me

[jhk-mjolner]

Had this too. Once I changed the useWorkerFactory to use module paths that can be resolved, it worked for me

Could you expand on that? What did you change more precisely, and was it with angular and/or webpack?

I've tried messing around with webpack config and aliases, and changing the paths in the useWorkerFactory, but didn't improve anything, only made errors about paths that didn't resolve or couldn't be found, which led me to believe the paths I have already did resolve.

[cdietrich]

Due to the way we bundle the url that was passed / calculated was wrong. Then the worker creation failed

I debugged to to find out the url it was requesting and then figured out my app does not deliver it due to the way we bundle

[jhk-mjolner]

Okay. I'll try looking further into that. Thanks.

Do you remember if there was any particular piece of documentation for webpack (or other) that helped you? Or was it just about finding what the browser requests, and where webpack (or your bundler) puts the files, and making them match?

[cdietrich]

yes i debugged the url, and then checked where it actually lands, and then passed the correct url
we were manually copying files around (and the paths had changed)

[jhk-mjolner]

Hmm, as far as I can tell, it resolves correctly.
The 'TextEditorWorker' URL object points to an address I can open in my browser and get exactly what is in the @codingame/monaco-vscode-editor-api/esm/vs/editor/editor.worker.js file:

export * from '@codingame/monaco-vscode-api/workers/editor.worker';

And the 'TextMateWorker' function apparently isn't called.

So URLs not resolving might not be my issue...

[cdietrich]

hmmm and its actually downloaded as well (network tab)

i use

    TextEditorWorker: () => {
      const u = new URL("../libs/monaco-editor-workers/editorWorker-es.js", import.meta.url)
      console.log(u.toString())
      return new Worker(u, {
        type: "module",
      })
    },

and see

let me check sth.

[jhk-mjolner]

It's weird. It appears in the network tab, but as 'pending' and with 0 B transferred, but if I doubleclick it, I can get the content in a new tab with no problem.

Only thing I can think of now is that something in the headers, that isn't present when loading it in a new tab, is causing the server not to respond...
like the sec-fetch-dest: worker header or something.

[cdietrich]

the -es.js file seems self contained the other one just does
export * from '@codingame/monaco-vscode-api/workers/editor.worker'

[jhk-mjolner]

Hmm, I don't have a -es.js file in @codingame/monaco-vscode-editor-api/esm/vs/editor/

Now I tried using the @codingame/monaco-vscode-api/workers/editor.worker url instead, and that causes my browser to try and load the /vscode/src/vs/editor/common/services/editorWorkerBootstrap.js path it exports, but the browser can't find it, probably because its relative path is now wrong.
So it's doing something with the 0 B pending result.
I also noticed that your image says 0 B, and my pending request still has a 200 OK status, so that part might not be so wrong after all.

[kaisalmen]

Hi @jhk-mjolner I just pushed an update to our verification examples including the webpack one (after x.3.0 release). There it works. Please, take a look at the webpack config and especially the worker related things:
https://github.com/TypeFox/monaco-languageclient/blob/main/verify/webpack/webpack.config.js
If I remember correctly these where needed to make it work.

And very important: Do not install the original monaco-editor package along with @codingame/monaco-vscode-editor-api package. I just realized we have to update our README. It is hidden in the Troubleshooting section and not explicitly stated / info is outdated.

You can even remove monaco-editor completely and just use it like that:

import * as monaco from '@codingame/monaco-vscode-editor-api';

[kaisalmen]

Got to verify/webpack and run npm run verify (it performs install and brings up the dev server):

[jhk-mjolner]

Thanks.

I've uninstalled the monaco-editor package, and updated the others to the x.3.0 releases.
I've been messing around with the webpack config options, but nothing seems to fix the problem.

In the verify/webpack project, I noticed that the loaded worker js file is a clearly webpack bundled file called vendors-node_modules_codingame_monaco-vscode-textmate-service-override_worker_js.main.js with lots of __webpack_this__ and __webpack_that__. But the file it tries to load for me is 320d512158e71419.js, and it's just the untransformed @codingame/monaco-vscode-editor-api/esm/vs/editor/editor.worker.js file with one export line in it.
So I think the problem is that webpack isn't actually transforming and bundling the file, but just taking it as-is, like an asset.
I haven't been able to find anything about that problem, except it's apparently important not to split the url out into a variable and give it to the worker constructor. It must be given directly, or webpack can't statically analyze it. But I'm doing that already.

Except for occasionally breaking things more, the changes I tried with the webpack config didn't change that it was output and fetched as an untransformed [hash].js file.
When I look at my compiled js code without sourcemaps, I also find that it says new Worker(new URL(/* asset import */ instead of /* worker import */ that I found somewhere should be the output, and is the output in the webpack/verify example.

I don't know why webpack does that wrong, or how to change it.

[kaisalmen]

@jhk-mjolner the one thing I can add here is that I have experienced that custom webpack used by ng behaves differently then direct webpack and that may explain your observation.

[cdietrich]

Hmm. With the latest version of the codingame packages I cannot find editorWorker-es.js
Anymore