-
-
Notifications
You must be signed in to change notification settings - Fork 34.7k
lib: include ESM loader in the built-in snapshot #61769
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
base: main
Are you sure you want to change the base?
Conversation
|
Review requested:
|
mcollina
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #61769 +/- ##
==========================================
+ Coverage 89.73% 89.77% +0.03%
==========================================
Files 675 674 -1
Lines 204648 204601 -47
Branches 39330 39320 -10
==========================================
+ Hits 183651 183686 +35
+ Misses 13282 13214 -68
+ Partials 7715 7701 -14
🚀 New features to boost your workflow:
|
watilde
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question for my understanding: I noticed defaultResolve and defaultLoadSync are still lazy-loaded with ??= while translators was moved to pre-loading. Is this because:
- These are only used when there are no custom loader hooks (less common path)?
- Their dependencies are heavier and would hurt startup more?
- Or is this something that could be optimized similarly in the future?
Just curious about the design rationale
Did you mean in |
Benchmark number from an ARM64 Linux machine: empty/minimal CJS startup is now slightly slower in worker but other metrics get a slight boost (because they all incur ESM loader initialization). In reality ESM loading is likely to happen at some point in the lifetime of an application especially with the growing adoption of ESM and
require(esm), so real-world applications that are more than just an empty script should get a bit of speed up from being able to just deserialize the ESM loader instead of initializing it from scrach.