webpack.config.ts is not compatible with Node.js v24

[marco-ippolito]

Bug report

What is the current behavior?

Refs: gulpjs/rechoir#49
Refs: nodejs/node#57298

Since rechoir is relying on the deprecated field require.extensions, with Node.js v24 having native typescript support, it will not load the typescript loader (ts-node etc...) and use type stripping which might support different syntax.

If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/hardfist/webpack-ts-break

What is the expected behavior?

It should not rely on require.extensions to check if the typescript loader is enabled.

Other relevant information:
webpack version:
Node.js version:
Operating System:
Additional tools:

[xiaoxiaojx]

@marco-ippolito hi, That's a bit strange — it works fine on my Node.js v24.

[marco-ippolito]

It works because you changed the .ts file to be compatibile with type stripping. In Node.js v22 this is not necessary. The reason is that under the hood it loads the typescript loader (I assume ts-node).
From Node.js v24 it detects the typescript loader as already loaded but in reality its the native type stripping

[xiaoxiaojx]

@marco-ippolito Got it, thanks. I’ll take a deeper look.

[xiaoxiaojx]

It doesn't seem to be a webpack issue — Node.js v24 discourages the use of __dirname within ES module scope. https://github.com/nodejs/node/blob/main/lib/internal/modules/esm/module_job.js#L77

[marco-ippolito]

It doesn't seem to be a webpack issue — Node.js v24 discourages the use of __dirname within ES module scope. https://github.com/nodejs/node/blob/main/lib/internal/modules/esm/module_job.js#L77

While that you can not use __dirname in esmodule is true, that is beside the point becase as you can see its type stripping from the experimental warning, its not being transpile by ts-node. When transpiled by ts-node you would not encour in this issue.
You can try executing it with Node.js v22 (where also its not possible to use __dirname is an es module)

[xiaoxiaojx]

Yes, it wasn’t compiled by ts-node because the environment has already detected support for .ts files.
https://github.com/gulpjs/rechoir/blob/master/index.js#L21

Whether we should always stick with ts-node here is still up for debate, as it might go against the standards introduced in Node.js v24.

[marco-ippolito]

Yes that is the issue. Before Node v24 require.extensions['.ts'] was undefined so it would load 'ts-node', with 24 require.extensions['.ts'] has a value because its used by Node.js itself. This behavior breaks existing configuration relying on ts-node rather than type stripping.
That makes it a breaking change and this does not allow node.js to enable type stripping in Node v22 to avoid breaking users nodejs/node#57298 (comment)

[xiaoxiaojx]

Although require.extensions is deprecated, having an API that informs users which file types are natively supported for load in the current Node.js version would still be valuable.
Since Node.js v24 adopts the new standard where __dirname is not supported within ES module scope, it's reasonable for users to adjust their code accordingly.

[marco-ippolito]

Since Node.js v24 adopts the new standard where __dirname is not supported within ES module scope, it's reasonable for users to adjust their code accordingly.

That is not a new standard, that is how it has always been. I think you misunderstood the issue. In the past it was working because it was being transpiled

[xiaoxiaojx]

Alright, Got it, thanks. Maybe when __dirname is no longer supported in the Node.js ES module scope, we should have prompted users to update their code. The fact that everything continued to work was only because previous versions were compiled with ts-node.
I'm not sure if we should keep supporting this—let's see what other maintainers think.

[marco-ippolito]

It's not just about __dirname, there is a lot of syntax that is not supported by type-stripping such as enums, module, etc... also the tsconfig is ignored

[alexander-akait]

I would rather say that this is a problem of webpack-cli - https://github.com/webpack/webpack-cli and documentation, not webpack itself, and current behavior was changed due to changes in Node.js, to be honest I don't see how we can solve this, you need to provide --loader/--require (and in future we are planning to remove rechoir and interpret at all)

i.e.

NODE_OPTIONS='--require ts-node/register' webpack --config webpack.config.ts

Let's update our documentation - here https://webpack.js.org/guides/typescript/#ways-to-use-typescript-in-webpackconfigts

[marco-ippolito]

That's correct, I'd drop rechoir and interpret. You can check if node.js has typescript support with process.features.typescript and rely on that

@naugtur