Angular 10, webpack, worker loader, large project
SamanthaAdrichem opened this issue · 3 comments
I know this often is not the platform for 'issues/help' unless it's a bug.
I honestly think it's a bug in either webpack, Angulars webpack configuration or in this loader. And I was hoping you could help me find the culprit and debug this issue.
I've created a stack overflow issue: https://stackoverflow.com/questions/64853849/angular-10-webworker-cannot-find-name-element-how-to-resolve
Long story short.
I've implemented the Angular webworker config which uses the worker loader using ng generate web-worker.
Then disabled all code in our current web worker and adjusted it to just a console.log.
Now the funny part is. I have a demo project, which is exactly the same configuration as our main project except that all the pages are gone and replaced with three dummy pages.
I've added a web worker according to the same syntax, and there it works fine. However in our main project (same config) we're getting TS errors about angular core 'Element not found', 'Node not foud' etc.
To me it feels like the web worker is getting bundled in a chunk with angular or something and that it then uses the webworker ts config on angular. Though the webworker is just a console.log and nothing more.
If I replace the 'webworker' in the lib part of the webworker tsconfig with 'dom' then it (logically) dies because it doesn't know the web worker event listeners. and you can't add them both.
So how can I debug this?
Same issue on my side
Hi there - this is a TypeScript error, right? It doesn't seem like the code is actually incorrect, it's just failing when validating types.
I noticed you're using a custom tsconfig.json for the worker - do you have this isolated off in its own directory?
Hey @developit the custom config was created by angular-cli when using ng generate worker and it's in the root project folder right besides the other configs.
The error itself clearly comes from that for some reason it's compiling an angular file into the worker that should not be co-compiled since it's not being used by the worker. I think it was some kind of cache mechanism in the compiler, which didn't clear itself properly with the code change. Because what we ended up doing was compile it once the old way, copy it and load the compiled version hardcoded. Then stop loading the uncompiled code.
(and since they are sharing interfaces)
Then in January I tried again and it just worked out of the box. (Thus it had no cached compile traces of the old compiled versions).
I forgot about the existence of this issue. So for me it can be closed.