module: refactor commonjs typescript loader

[marco-ippolito]

Refs: nodejs/typescript#37

As suggested by @joyeecheung nodejs/typescript#37 (comment), we can refactor the commonjs loader so that we dont have to expose in the Module._extensions the TypeScript file extensions.

This also means that require.extensions will be inconsistent but it already is since .cjs and .mjs are not exposed

This should unblock the backport of Type Stripping in Node v22.

I tested it against @hardfist https://github.com/hardfist/webpack-ts-break and it fixes the breaking change:

Node v24
marcoippolito@marcos-MacBook-Pro-3 webpack-ts-break % node  node_modules/webpack/bin/webpack.js
[webpack-cli] Failed to load '/Users/marcoippolito/Documents/projects/test/webpack-ts-break/webpack.config.ts' config
[webpack-cli] ReferenceError: __dirname is not defined
    at /Users/marcoippolito/Documents/projects/test/webpack-ts-break/webpack.config.ts:5:12
    at ModuleJobSync.runSync (node:internal/modules/esm/module_job:455:35)
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:435:47)
    at loadESMFromCJS (node:internal/modules/cjs/loader:1565:24)
    at Module._compile (node:internal/modules/cjs/loader:1716:5)
    at Object.loadTS [as .ts] (node:internal/modules/cjs/loader:1826:10)
    at Module.load (node:internal/modules/cjs/loader:1469:32)
    at Module._load (node:internal/modules/cjs/loader:1286:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
    
    
This PR
marcoippolito@marcos-MacBook-Pro-3 webpack-ts-break % ../../forks/node/out/Release/node node_modules/webpack/bin/webpack.js
asset main.js 21 bytes [emitted] [minimized] (name: main)
./src/index.js 20 bytes [built] [code generated]
webpack 5.99.9 compiled successfully in 100 ms

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

Attention: Patch coverage is 78.94737% with 4 lines in your changes missing coverage. Please review.

Project coverage is 90.15%. Comparing base (a45f1ad) to head (c942d9f).
Report is 142 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/modules/cjs/loader.js	78.94%	4 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #58657   +/-   ##
=======================================
  Coverage   90.14%   90.15%           
=======================================
  Files         636      636           
  Lines      188030   187953   -77     
  Branches    36894    36882   -12     
=======================================
- Hits       169506   169451   -55     
+ Misses      11276    11268    -8     
+ Partials     7248     7234   -14     

Files with missing lines	Coverage Δ
lib/internal/modules/cjs/loader.js	97.85% <78.94%> (+0.06%)	⬆️

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

[mcollina]

lgtm

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[hardfist]

@marco-ippolito great job! may I ask whether this compatible fix be backported to Node.js 23&24? we're willing to migrate to native typescript support but a easier progressive migration is always preferred.

[marco-ippolito]

v24 yes in the next release
v23 no since is eol

[nodejs-github-bot]

Landed in 708477b

[JLHwung]

With this change, how should a library detect if the current node has enabled builtin strip-types support? Should a library do the version check?

Previously in Babel we checked require.extensions (set by ts-node, tsx or node < 24.3) and nudged users to upgrade Node or install the aforementioned libraries if they want to use a TS Babel config file such as babel.config.cts.

[marco-ippolito]

With this change, how should a library detect if the current node has enabled builtin strip-types support? Should a library do the version check?

Previously in Babel we checked require.extensions (set by ts-node, tsx or node < 24.3) and nudged users to upgrade Node or install the aforementioned libraries if they want to use a TS Babel config file such as babel.config.cts.

process.features.typescript
https://nodejs.org/api/process.html#processfeaturestypescript