webpack.js.org

webpack.js.org copied to clipboard

Feature to document

I noticed that the recommendations for using ts-node to load webpack.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-paths

Second, the recommended configuration should be updated to recommend using moduleTypes instead of compilerOptions

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 to require() 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 a webpack.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.

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