-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to ESM #335
Migrate to ESM #335
Conversation
Things I'm stuck on at the moment (just to keep records):
Also:
|
Try to remove it. Maybe we don’t need it anymore (by increasing performance with new Node.js and esbuild).
Need some example to understand what exactly problems do you have
If it is only a few bytes, it could happen just because of dependencies update (new esbuild compress a little different). Just updates tests and snapshots. |
Some tests fail due to snapshot mismatch, but the difference is too big. For example, "supports ignore" generates 405 bytes instead of 231.
For some reason, Webpack doesn't bundle the files; the final size is 70 bytes (expected 1450)
Alright, this is mostly done now, only couple of bugs left.
Currently stuck on
Seems like the non-JS requires inside
For the "supports ignore" test on esbuild, it doesn't seem to, well, support |
70 bytes is nothing. Just update the size.
This is more important bug. But with the current data I can’t give you any advice rather than keep debuging. |
How so? It is expected that the final webpack bundle is in the 1450–2400 range, but it's just 70 (which coincidentally matches the size of the unbundled file), so 2–3 orders of magnitude smaller. |
Got it! Yes, it is not expected (I thought that it is 70 less, not equal to 70). |
Closing for #338 |
231405 bytes)test/get-running-time.test.js > calculates running time
doesn't run on my machine, both Jest and Vitest145070 bytes)