esm: syncify default path of ModuleLoader.load

[JakobJingleheimer]

In #57390 I somehow inadvertently created a branch on the node repo instead of my fork, and then got stuck.

Parent issue: #55782

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.23%. Comparing base (9df0ff7) to head (a2d0fcc).
Report is 80 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main   #57419    +/-   ##
========================================
  Coverage   90.23%   90.23%            
========================================
  Files         630      629     -1     
  Lines      185200   184914   -286     
  Branches    36233    36223    -10     
========================================
- Hits       167108   166854   -254     
+ Misses      11056    11016    -40     
- Partials     7036     7044     +8     

Files with missing lines	Coverage Δ
lib/internal/modules/esm/load.js	94.31% <100.00%> (+2.36%)	⬆️
lib/internal/modules/esm/loader.js	95.04% <100.00%> (ø)
lib/internal/modules/esm/resolve.js	96.17% <100.00%> (ø)

... and 71 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.

[marco-ippolito]

I investigated a bit on the weird failure and apparently there is some scheduling issue.
it can be patched with marco-ippolito@e0d702b#diff-b4c24f634e3741e5ad9e8c29864a48f2bd284a9d66d8fed3d077ccee0c44087bR968 but idk why it happens

[JakobJingleheimer]

Sweet, thanks! I was gonna take a look this evening. I'll apply it as soon as I finish work 🙂

[JakobJingleheimer]

I think this test's setup is the actual issue (I'm not sure why it was ever working 🤔):

• global-hooks.js contains a non-awaited dynamic import at the root: import('node:test').then((test) => …)
• The global hooks setup file --import/--require'd itself is indeed run before the test files (added console.log('\n==global hooks==\n') at line 1, and it prints first).

I suspect it was set up this way in order to re-use for both cjs and esm. @avivkeller it looks like you authored this test ~6 months ago. Would you perchance remember whether there was another reason? I can't think of one, but if there is, my change could inadvertently cause something to no-longer be covered.

Splitting global-hooks.js into global-hooks.cjs + require & global-hooks.mjs + static import, the sequence issue appears to be fixed.

However, a few of the global test hooks are now just not printing at all for the --require case (red lines are missing in actual vs expected):

before(): global
before one: <root>
suite one
before two: <root>
suite two
- beforeEach(): global
beforeEach one: suite one - test
beforeEach two: suite one - test
suite one - test
- afterEach(): global
afterEach one: suite one - test
afterEach two: suite one - test
before suite two: suite two
- beforeEach(): global
beforeEach one: suite two - test
beforeEach two: suite two - test
suite two - test
- afterEach(): global
afterEach one: suite two - test
afterEach two: suite two - test
- after(): global
after one: <root>
after two: <root>