Node Workers broken during test on 4.0
ibgreen opened this issue · comments
Observations:
- Node workers seem to be loaded by tsnode, which typechecks the code before running it. The built code triggers a lot of warnings/errors. Adding a line
// @ts-nocheckto the start of the built code mitigates this. - There are import issues. Building the node-workers with
--format=esmminimizes problems. - The polyfills module bundles the image polyfills. These are old school and generate requires / dynamic imports that break the esm module initialization.
Still not clear why these things are an issue for workers but not for normal code.
The issue is actual only for test node environment. The tile-converter that uses workers works correctly.
The test envirionment works on custom esm loader: https://github.com/uber-web/ocular/blob/731cac03c4f2f8484f9e244d61af2eb3b445f95a/modules/dev-tools/src/test.js#L90 . The problem is that the workers are also run with this custom loader. It seems that it tries to handle the .js workers as TypeScript.
I've tried to play with tsconfig, custorm esm-loader, --format=esm, usage of .cjs extesion but haven't found a definitive solution yet.
OK that is good info. So you would be open to not considering this a blocker for shipping 4.0.0 production, but instead we can work to fix it afterwards?
I agree. We just need a few days to test the converter manually because we cannot be sure that everything is ok, especially without automated tests. Can we cut the release branch from last beta version . We would make 4.0.0 latest from 4.0.0-beta.8
Can we cut the release branch from last beta version.
Yes. I don't think we need to cut a 4.0-release branch until we start diverging for 4.1. We can publish 4.0.0 from master for now.
We would make 4.0.0 latest from 4.0.0-beta.8.
Yes let's sync when your testing is ready. I am doing some final polish also. Then we just publish 4.0.0 from master with yarn run publish prod.
The problem is that the workers are also run with this custom loader. It seems that it tries to handle the .js workers as TypeScript.
I wonder if this means that we could now make the node workers in test import from source rather than dist? Not sure if that is a good idea, and I guess it would take some work to generate the different paths in the two cases.
Yes. I don't think we need to cut a 4.0-release branch until we start diverging for 4.1. We can publish 4.0.0 from master for now.
Our QA is testing 4.0.0-beta.8 . If master will be on this commit, we can publish from master. If there are new commits on top of 4.0.0-beta.8 I would suggest publishing from 4.0-release because we won't be sure that the code is not broken with new commits.
At this time we are in a sort of code freeze, the final stabilization and polish phase. We are not landing any new features or refactors at this time, but we may need to make some final fixes if we find issues during test integrations and audits.
Let's look at the commits in question if it happens. If they are 100% unrelated to your tile-converter we should be good.