Automatically `--disable-interpret` on Node 22.18+

[fregante]

Feature request

Import webpack.confg.ts with native TS support, without interpreters, by default.

What is motivation or use case for adding/changing the behavior?

Node 22.18+ can read TS just fine, actually it can do so better than webpack's interpreters in some case.

I tried using await import in the config and I bumped into this error:

ERROR: Top-level await is currently not supported with the "cjs" output format

which lead me to realized that I was still using the esbuild interpreter webpack found in node_modules rather than the native "strip ts types" Node.js feature.

How should this be implemented in your opinion?

If native TS support is detected, it should default to --disable-interpret.

Are you willing to work on this yourself?

no

[alexander-akait]

Yes, that would be a good change, unfortunately it will be a breaking change in the next major release we will remove interpret at all, you will need specify custom require/import using:

NODE_OPTIONS='--import tsx'  webpack -c ./webpack.config.ts

[silverwind]

FYI you can check typescript support via process.features.typescript.

you will need specify custom require/import using:

Will it not be possible without any --import preloading? If process.features.typescript is truthy, await import("webpack.config.ts") will work without any additional dependencies.

[alexander-akait]

@silverwind We can't change it without breaking changes, because some developers can rely on tsx/esbuild/babel and etc output and can break something

Will it not be possible without any --import preloading?

You will need to always specify require/import in the next major release, interpret and rechoir is not good maintained now (and don't support a lot of new tools especial around ES modules) and takes a build time (because we are looking installed deps, trying to apply/etc, under the hood of interpret), also less deps - less problems, that is why I think adding an extra --import if you want to use esbuild/tsx/etc is simple and good solution, and make build faster

[fregante]

I'll clarify some misunderstandings here:

• in webpack 6, you won't need NODE_OPTIONS='--import tsx' if you use Node's native TS support, it will be native and automatic
• you can't "automatically --disable-interpret" now because Node TypeScript support is not at all equivalent to esbuild

So I'll close this issue and we'll wait for Webpack 6, if it ever comes out.

[alexander-akait]

in webpack 6, you won't need NODE_OPTIONS='--import tsx' if you use Node's native TS support, it will be native and automatic

Yes, it will work without any import/require if Node.js has native TS support, and it will be part of webpack-cli@6 (September), not webpack itself, we specifically keep webpack and webpack-cli as separate packages to make release and breaking changes more frequently

[alexander-akait]

@fregante let's keep open to not lose this issue

[fregante]

However one could still argue that interpret relied on external/environmental packages, automatically detecting and using them in whichever order it decided.

This is how I ended up here: I don't have esbuild among my dependencies, I did not ask Webpack to use it, but somehow it made its way into node_modules (via vitest?) and now interpret (and webpack) automatically uses it.

In short, interpret might as well decide to find and use "Node-TS" as the interpreter. Under this light, it's not strictly breaking, as it has always relied on the presence of external interpreters.

Anyone preferring a specific interpreter, has always been able to explicitly use --import

[fregante]

it will be part of webpack-cli@6 (September),

Oh, that sounds good then! Let's just wait for that.

[alexander-akait]

Technically you are right, but I think in this case interpret should response for this as fallback, it is more about fixing the problem on their side, anyway I think it is time to drop interpret and other stuff, they are very outdated...

[alexander-akait]

Resolved, we will make a new major release next week, by default we will use import(...), if error - we will use require with interpret, so by default we will try to use built-in typescript and than fallback