test: add smoke tests for defer importing synthetic modules

[MayaLekova]

test: add smoke tests for defer importing synthetic modules

The tests added ensure that Node.js doesn't crash or produce incorrect results when importing synthetic modules (i.e. JSON, text or builtin modules) with the defer modifier.

Signed-off-by: Maya Lekova maya@igalia.com

[MayaLekova]

@joyeecheung and @nicolo-ribaudo could you take a look please? Just a few smoke tests for synthetic modules.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (46a7dbd) to head (414cd49).
⚠️ Report is 16 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #65537      +/-   ##
==========================================
- Coverage   90.21%   90.12%   -0.09%     
==========================================
  Files         751      751              
  Lines      253550   253635      +85     
  Branches    47813    47793      -20     
==========================================
- Hits       228733   228600     -133     
- Misses      16076    16276     +200     
- Partials     8741     8759      +18     

see 46 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.

[nicolo-ribaudo]

The tested behavior looks correct to me.

For the node:fs, is there any way to test when evaluation happens? Maybe if one monkey-patches some built-ins before evaluating node:fs then it does something different? (I hope the answer is "no it's not possible")

[MayaLekova]

is there any way to test when evaluation happens?
I thought about it, couldn't think of a straight-forward way at first. Monkey-patching might be a reasonable way, I'll give it another try.

If the builtin was to write something to the global namespace, that would make it easier. But I guess they don't do so, in order no to pollute the global namespace. Also there might be another builtin module that writes something on globalThis.