Jason Miller

Agreed - best practise I'd recommend for everyone using `workerize-loader` is to use async/await or Promises in your module. That way, there's no interface difference created by applying workerize, it...

Yup, make sure to import a polyfill your code depends on.

import regenerator in your worker file: ```js // foo.worker.ts import 'regenerator-runtime'; // your code ```

Sorry for the very long delay there - this is likely due to the `.splitText` dependency: ```js Text.prototype.splitText = () => {}; ```

I believe `worker-loader` supports it. Isn't SharedWorker deprecated though?

This is likely an issue with Webpack not passing `externals` to child Compiler instances.

If someone wants to open a PR that copies `compiler.options.external` to the ChildCompiler instance that should fix the Webpack error here. Personally I'm not sure externals in the Worker compiler...

Are you using a plugin to clear your output directory? If so, that will break this plugin. #6 provides a way forward that would circumvent this issue.

Looks like this might also be related to `[chunkhash]`, which I just added support for.

Sounds like #6 would be ideal here.