feat: Web Worker Support

hmil / tslint-override

TSLint plugin bringing support for the override keyword

MIT License

27 stars 6 forks source link

feat: Web Worker Support #34

Closed wSedlacek closed 4 years ago

wSedlacek commented 4 years ago

Doesn't assume that window is defined when global is undefined
Exports Override() and override() so they can be imported in the cases where they aren't defined globally (like in Web Workers)

fixes: #33

[x] Prevent Errors when running angular-register inside of a Web Worker
[x] Access @Override() and @override() from the Web Worker global
[x] ~~Register at the main entry point rather then for each worker~~
[x] Apply the same fixes to register

wSedlacek commented 4 years ago

This is a purposed solution, that would require the import of the decorators into Web Workers. Not entirely happy with the ergonomics but figured I would make the PR so you can take a look at it and provide some feedback.

wSedlacek commented 4 years ago

Using self does improve things, however since each Web Worker is still an entry point it seems that TypeScript isn't happy unless each Web Worker is registered independently.

This could just be an Angular thing though as the error is coming from the @angular-devkit

client:159 ./src/app/app.worker.ts (.../node_modules/@angular-devkit/build-angular/node_modules/worker-plugin/dist/loader.js?name=10!./src/app/app.worker.ts)
Module build failed (from .../node_modules/@angular-devkit/build-angular/node_modules/worker-plugin/dist/loader.js):
Error: apps/samples/basic/src/app/app.worker.ts:7:4 - error TS2304: Cannot find name 'Override'.

hmil commented 4 years ago

This is getting uncomfortably over-engineered for just the comfort of being able to write @Override outside of a JSDoc comment.

I can merge it if you figure out how to get it to work, but I don't think I'll have any bandwidth to look into this myself anytime soon.

wSedlacek commented 4 years ago

😅 I am not super happy about it either. Give me about a week to think about it some and see if I can't come up with any other solutions.

As it stands the self does work inside workers, however it requires each worker to be registered. Modifying the Global Object certainly is needlessly complicated.

wSedlacek commented 4 years ago

So after doing some more research the limitation of registering with web workers globally appears to be one of Web Pack.

In this similar issue about polyfills for angular it more or less describes this https://github.com/angular/angular-cli/issues/15033 Additionally tooling.report seems to collaborate this issue with their failing test. https://bundlers.tooling.report/code-splitting/

Maybe at some point in the future something like this will be supported in Web Pack and improve the ergonomics. I do still believe that the changes made thus far in this PR are still useful as it prevents errors from occurring in the worker environment which would be required when/if Web Pack can ever do registration globally.

I will go ahead and bring the standard register up to date with this PR.

hmil commented 4 years ago

@wSedlacek Please test v1.0.1 of the package and let me know if there's any issue.

wSedlacek commented 4 years ago

@wSedlacek Please test v1.0.1 of the package and let me know if there's any issue.

Working for my use cases. Thank you!