webpack
Automatically `--disable-interpret` on Node 22.18+
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
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
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.
@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
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.
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
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
it will be part of webpack-cli@6 (September),
Oh, that sounds good then! Let's just wait for that.
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...