fix: module.exports on CJS modules

[guybedford]

Resolves #57295.

While the special "module.exports" name was defined for exporting from ESM modules for their representation in CommonJS, when writing a CommonJS with a "module.exports" export name will cause a V8 error.

The actual issue here is that we don't check if module.exports is already an export when defining the module wrap exports and as a result it is defined twice causing the failed V8 check.

To avoid unnecessary work, we also update the code path to instead of settin this export and then override it later, just not setting it at all. To avoid unnecessary hasOwnProperty checks, these checks are moved earlier in the sequence as well.

//cc @nodejs/loaders

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.21%. Comparing base (27f98c3) to head (7c1bb9b).
Report is 241 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #57366   +/-   ##
=======================================
  Coverage   90.20%   90.21%           
=======================================
  Files         630      630           
  Lines      185307   185311    +4     
  Branches    36269    36270    +1     
=======================================
+ Hits       167162   167173   +11     
- Misses      11084    11090    +6     
+ Partials     7061     7048   -13     

Files with missing lines	Coverage Δ
lib/internal/modules/esm/translators.js	91.57% <100.00%> (+0.06%)	⬆️

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

[nodejs-github-bot]

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

[guybedford]

CI seems to be fully passing here except for the ubuntu2204-armv7l runner which seems to have some problems starting up. Unless anyone objects will land anyway tomorrow.

[richardlau]

CI seems to be fully passing here except for the ubuntu2204-armv7l runner which seems to have some problems starting up. Unless anyone objects will land anyway tomorrow.

They're failing in the fanned job because they succeeded in https://ci.nodejs.org/job/node-test-pull-request/65639/ and the temporary binaries were deleted. Basically https://ci.nodejs.org/job/node-test-pull-request/65639 and https://ci.nodejs.org/job/node-test-pull-request/65640/ raced each other and now the only way to get a clean CI run would be to start a new one (not resume).

[guybedford]

Landed in fbe37d5.

[RafaelGSS]

This commit didn't land cleanly on v22.x-staging. It requires a manual backport, so I'm adding a backport-requested label.

Should probably be backported along with #55844 to minimize the amount of conflicts.