Ingvar Stepanyan

Or, actually, could as well put the regexp first and start at "#" then like `regex#[derive(Default)]` or `regex=#[derive(Default)]` or even just `regex=derive(Default)` avoiding '#' completely.

Got bitten by this too, but can't find what would be the way to fix it in he...

It appears it already is an error in `strict` mode for `he`.

I'm running into an issue where `new Worker(new URL(...))` syntax used with a worker target that uses e.g. ```js this.onmessage = console.log; ``` silently produces a broken worker that contains...

Well... that's pretty much it. Put the code above: ```js this.onmessage = console.log; ``` in e.g. `worker.js` and then in `main.mjs` put ```js new Worker(new URL('./worker.js', import.meta.url)); ``` And compile...

Perhaps it's assuming that any Worker is ESM and hence strict by default, when it should be looking for `new Worker(..., {type: 'module'})` to determine whether it's a script Worker,...

@sokra I'm aware it's not the same. That's what I'm saying - that Webpack seems to assume that Worker is always a module, whereas by default in browsers it's a...

Perhaps it would be easiest for Webpack to just skip over workers without `type: 'module'` for now? Unless there's an easy way to tell it that others are regular scripts...

Yeah I guess that works as a workaround - in my case I went ahead and updated that legacy Worker that caused an issue to be strict mode compliant. I...

> The bundlesize is a little bigger now, but IMO the performance gain is worth it. Why? No-op spinning loop shouldn't have any significant impact (and might be even optimised...