lib: include ESM loader in the built-in snapshot

[joyeecheung]

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.

                                                                                         confidence improvement accuracy (*)   (**)  (***)
misc/startup-core.js n=30 mode='process' script='benchmark/fixtures/empty.mjs'                  ***      6.06 %       ±0.60% ±0.80% ±1.04%
misc/startup-core.js n=30 mode='process' script='benchmark/fixtures/import-builtins.mjs'        ***      2.40 %       ±0.30% ±0.40% ±0.52%
misc/startup-core.js n=30 mode='process' script='benchmark/fixtures/require-builtins.js'        ***      0.57 %       ±0.32% ±0.42% ±0.55%
misc/startup-core.js n=30 mode='process' script='test/fixtures/semicolon.js'                            -0.22 %       ±0.56% ±0.75% ±0.97%
misc/startup-core.js n=30 mode='worker' script='benchmark/fixtures/empty.mjs'                   ***      1.89 %       ±0.26% ±0.34% ±0.44%
misc/startup-core.js n=30 mode='worker' script='benchmark/fixtures/import-builtins.mjs'         ***      0.74 %       ±0.28% ±0.38% ±0.49%
misc/startup-core.js n=30 mode='worker' script='benchmark/fixtures/require-builtins.js'         ***     -2.20 %       ±0.26% ±0.34% ±0.44%
misc/startup-core.js n=30 mode='worker' script='test/fixtures/semicolon.js'                     ***     -1.95 %       ±0.30% ±0.40% ±0.52%

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/performance
• @nodejs/startup

[mcollina]

lgtm

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.75%. Comparing base (37ff1ea) to head (21bdb3d).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61769      +/-   ##
==========================================
+ Coverage   89.74%   89.75%   +0.01%     
==========================================
  Files         675      674       -1     
  Lines      204735   204750      +15     
  Branches    39348    39341       -7     
==========================================
+ Hits       183737   183781      +44     
+ Misses      13269    13254      -15     
+ Partials     7729     7715      -14     

Files with missing lines	Coverage Δ
lib/internal/bootstrap/switches/is_main_thread.js	95.92% <100.00%> (+0.01%)	⬆️
lib/internal/modules/esm/get_format.js	94.83% <100.00%> (+1.68%)	⬆️
lib/internal/modules/esm/loader.js	98.76% <100.00%> (+1.79%)	⬆️
lib/internal/modules/esm/resolve.js	98.94% <100.00%> (+2.74%)	⬆️
lib/internal/modules/esm/translators.js	97.64% <100.00%> (+5.26%)	⬆️
lib/internal/process/pre_execution.js	95.98% <100.00%> (+0.01%)	⬆️
lib/internal/repl/completion.js	95.13% <100.00%> (ø)

... and 42 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[watilde]

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

[joyeecheung]

I noticed defaultResolve and defaultLoadSync are still lazy-loaded with ??= while translators was moved to pre-loading.

Did you mean in esm/loader.js? I believe I've removed them. If not could you leave a pointer to the line where it still remains? Happy to update them in this PR.

[watilde]

My code base in my local was very old, nvm. Thank you!

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71322/

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/61769
✔  Done loading data for nodejs/node/pull/61769
----------------------------------- PR info ------------------------------------
Title      lib: include ESM loader in the built-in snapshot (#61769)
Author     Joyee Cheung <joyeec9h3@gmail.com> (@joyeecheung)
Branch     joyeecheung:esm-in-snapshot -> nodejs:main
Labels     lib / src, needs-ci, commit-queue-rebase
Commits    3
 - lib: remove top-level getOptionValue() calls in lib/internal/modules
 - lib: reduce cycles in esm loader and load it in snapshot
 - benchmark: add startup benchmark for ESM entrypoint
Committers 1
 - Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/61769
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/61769
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
--------------------------------------------------------------------------------
   ℹ  This PR was created on Wed, 11 Feb 2026 04:52:49 GMT
   ✔  Approvals: 3
   ✔  - Matteo Collina (@mcollina) (TSC): https://github.com/nodejs/node/pull/61769#pullrequestreview-3782914586
   ✔  - Daijiro Wachi (@watilde): https://github.com/nodejs/node/pull/61769#pullrequestreview-3784562017
   ✔  - Geoffrey Booth (@GeoffreyBooth): https://github.com/nodejs/node/pull/61769#pullrequestreview-3787902819
   ✘  Last GitHub CI failed
   ℹ  Last Full PR CI on 2026-02-12T15:02:50Z: https://ci.nodejs.org/job/node-test-pull-request/71322/
- Querying data for job/node-test-pull-request/71322/
✔  Build data downloaded
- Querying failures of job/node-test-commit/85439/
✔  Data downloaded
   ✘  44 failure(s) on the last Jenkins CI run
--------------------------------------------------------------------------------
   ✔  Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/21975249143

[joyeecheung]

Looks like this got broken by #61665 which added filtering of internal frames but the regex couldn't understand async frames. Updated the regex to handle async frames. cc @legendecas

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71334/

[joyeecheung]

Looks like the new regex didn't work with test runner outputs somehow. Updated. Can you take a look again? @legendecas Thanks!

[TheOneTheOnlyJJ]

Is node:sqlite omitted intentionally from here?

[joyeecheung]

It's copied from the require-builtins which predated sqlite. Can update both in a follow up (I think there are probably a few other newer builtins not included too).

[TheOneTheOnlyJJ]

I'm wondering if there could be a new lint rule just to keep these 2 files up to date at all times? I'm not knowledgeable enough in ESLint to implement this, but maybe it is a viable path to ensure these files do not get left behind as builtins change (added, removed, renamed) over time.

[joyeecheung]

IMO a lint rule is a bit of an overkill - that kind of put the pressure on anyone who adds a new built-in to run the benchmark and measure its loading performance when that's not really a universally important metrics for all builtins. For builtins that are changed or removed we have already smoking benchmark tests to ensure these benchmarks don't throw.