frontend-plugin: fix creating a webworker for frontend plugin (browser only)

[vitaliy-guliy]

Signed-off-by: Vitaliy Gulyy vgulyy@redhat.com

What it does

After moving to webpack 5, frontend plugins were not working for some time. Now it's not necessary to create a worker-loader.
It's enough to create a worker, pointing on javascript file.
https://webpack.js.org/guides/web-workers/

It's still not possible to create a worker for electron browser. Frontend plugins were turned off and the appropriate check for the browser was added to the hosted-plugin.ts.

Partially solves #6601

How to test

• Clone and build Theia
• Create a hello-world theia frontend plugin
• Run browser version of Theia with the plugin

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[vince-fugnitto]

I confirmed with the hello-world theia plugin that frontend plugins work again for the browser use-case 👍

[tsmaeder]

As I understand it, including the hash will make sure we're not referencing stale code from the cache. Can we find a way to preserve that feature?

[vitaliy-guliy]

Nothing is impossible, but since we don't need a worker-loader we need to keep somewhere the file name.
Before it was inside generated worker-loader script

  return new Worker(__webpack_require__.p + "worker-ext.5f6918e41dd2b417d716.js");

For now we need to keep somewhere a proper name of the file and fetch it before running a worker.

Btw, other javascript files don't have hash in their names. Do we really need to have it only for this specific file?

[tsmaeder]

I think we should turn off front-end plugins more cleanly in the electron case. Beyond that, I there are a couple of changes I just don't understand. It would help if you described hat the fix is a bit in the PR description.

Don't want the PR to be blocked while I'm on vacation

[paul-marechal]

@vitaliy-guliy why should we avoid using worker-loader?

Modifying the generated Webpack configuration like you did will not work if we don't include @theia/plugin-ext right?

[vitaliy-guliy]

@vitaliy-guliy why should we avoid using worker-loader?

With Webpack 5 we can use webworker without worker loader https://webpack.js.org/guides/web-workers/

I've tried to use it with loader and create a worker using a require as it was before, but it does not work.
Nothing happens as well if I run worker-loader

new Worker(worker-loader script)

Modifying the generated Webpack configuration like you did will not work if we don't include @theia/plugin-ext right?

Yes, it will fail, plugin-ext must be included. I will think how to improve it and make the build successful without plugin-ext.

[vitaliy-guliy]

@paul-marechal I played with dependencies a bit, but was easily compile the browsrer/electron.
I think it's because plugin-ext is still physically present on the file system and could be found when running webpack.

[paul-marechal]

I think it's because plugin-ext is still physically present on the file system and could be found when running webpack.

So it only works in the Theia repo but will most likely fail in a downstream Theia app.

With Webpack 5 we can use webworker without worker loader https://webpack.js.org/guides/web-workers/

I've tried to use it with loader and create a worker using a require as it was before, but it does not work.
Nothing happens as well if I run worker-loader

new Worker(worker-loader script)

I played around with what the Webpack doc was saying: https://github.com/eclipse-theia/theia/compare/mp/frontend-plugins#diff-6ccaef7f7e0ffcd2911ccf76fd97fbe9f2e75f1009ddda5c9024d9807bb093a3R30-R35

It worked for me without the changes to the application-manager generators.

[vitaliy-guliy]

I played around with what the Webpack doc was saying: https://github.com/eclipse-theia/theia/compare/mp/frontend-plugins#diff-6ccaef7f7e0ffcd2911ccf76fd97fbe9f2e75f1009ddda5c9024d9807bb093a3R30-R35

It worked for me without the changes to the application-manager generators.

I always get an error, when I try to create an URL with import.meta.url

packages/plugin-ext/src/hosted/browser/plugin-worker.ts:30:52 - error TS1343: The 'import.meta' meta-property is only allowed when the '--module' option is 'esnext' or 'system'.

30         const workerURI = new URL('./worker-main', import.meta.url);
                                                      ~~~~~~~~~~~

That's why I used location.href instead.
But seems // @ts-expect-error (TS1343) helps to compile ignoring the error.

[vitaliy-guliy]

@paul-marechal I've updated the PR, based on your branch. Seems it works fine.
Thanks!

[paul-marechal]

LGTM!

[paul-marechal]

That's why I used location.href instead.
But seems // @ts-expect-error (TS1343) helps to compile ignoring the error.

Did it work with location.href? I only used import.meta.url because I thought it is a pattern Webpack is looking for to do the proper transformations, but maybe something else would also be detected by Webpack? I'm fine with the current changes anyway.

[vitaliy-guliy]

That's why I used location.href instead.
But seems // @ts-expect-error (TS1343) helps to compile ignoring the error.

Did it work with location.href? I only used import.meta.url because I thought it is a pattern Webpack is looking for to do the proper transformations, but maybe something else would also be detected by Webpack? I'm fine with the current changes anyway.

It works with location.href, but I have to create an URL referring on compiled javascript, not the typescript file.

[paul-marechal]

Out of curiosity I tried the following:

this.worker = new Worker(new URL('./worker/worker-main', location.href));

It didn't work at all... So import.meta.url it is then!