Open cspotcode opened 2 years ago
I suppose one other thing worth clarifying, this is technically incorrect, though it may not be worth changing:
This occurs because ts-node does not support any module syntax other than commonjs.
We do fully support native ESM module syntax. But since webpack can't install a node --loader
at runtime, the pragmatic hoice is to run as CJS instead.
Can you share the link where on https://webpack.js.org we have to make updates?
Yes, apologies I forgot to include a link. Here it is:
https://webpack.js.org/configuration/configuration-languages/
Linking to the issue and PR that add cts support to interpret:
https://github.com/gulpjs/interpret/issues/89 https://github.com/gulpjs/interpret/issues/90
I ran into this problem today as well and noticed the docs we're outdated.
You can specify a loader by using the NODE_OPTIONS
environment variable:
{
...
"scripts": {
...
"build": "cross-env NODE_OPTIONS=\"--loader ts-node/esm\" webpack ..."
}
}
This also allows TS_NODE_PROJECT
to be passed in as well to config ts-node
.
In the current version of Node (18) this throws a warning but it can be hidden by passing the cli arguments: --no-warnings --experimental-specifier-resolution=node
.
I agree with @cspotcode points and this section needs to be tweaked or re-written as there are better ways of using ts-node now.
Makes sense, currently we have this information mentioned here https://webpack.js.org/api/cli/#troubleshooting
Feature to document
I noticed that the recommendations for using
ts-node
to loadwebpack.config.ts
can be simplified: https://webpack.js.org/configuration/configuration-languages/First,
TS_NODE_PROJECT
environment variable is supported natively by ts-node; no need to install tsconfig-pathsSecond, the recommended configuration should be updated to recommend using
moduleTypes
instead ofcompilerOptions
https://typestrong.org/ts-node/docs/module-type-overrides
moduleTypes
is better because it not only modifies the emitted code to be CommonJS, it also tells node to execute the files as CommonJS. This avoids node errors about attempting torequire()
ESM modules.Note that I've also merged support for CJS and CTS file extensions, to be published in our next release in a week or two. So if webpack supports
webpack.config.cts
, then that is an even simpler option. With awebpack.config.cts
,moduleTypes
is not necessary unless the config tries to import other files that are ESM TS.Author(s)
Additional information
[x] I am willing to work on this issue and submit a pull request.