Open evenstensberg opened 1 year ago
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.
Does this refactor mean that we can write webpack.config.js
in ESM without relying on the package.json "type": "module"
because an ESM can easily import another ESM?
There is currently some serious bug on TypeScript's new option "moduleResolution": "bundler"
when "type": "module"
is set, and it's clearly stated on their documentation regarding working with bundler: https://www.typescriptlang.org/docs/handbook/modules/guides/choosing-compiler-options.html#im-using-a-bundler.
In addition to adopting the following settings, it’s also recommended not to set { "type": "module" } or use .mts files in bundler projects for now. Some bundlers adopt different ESM/CJS interop behavior under these circumstances, which TypeScript cannot currently analyze with "moduleResolution": "bundler". See issue #54102 for more information.
I want to know whether this issue can remove the need for "type": "module"
. The related issue of TypeScript#54102 is https://github.com/webpack/webpack/issues/17288.
You already can do it, we support commonjs and ESM formats
@alexander-akait I can't. I got an error:
Notice that I didn't use @babel/register
with config name webpack.config.babel.js
and I didn't add "type": "module"
in package.json. By webpack support with the consideration above, I should not add "type": "module"
in package.json.
✔ ~/GitHub/Frontend % npm run dev development 20:41:36
> frontend@0.0.1 dev
> webpack server --mode development
[webpack-cli] Failed to load '/Users/ningwang/GitHub/Frontend/webpack.config.js' config
[webpack-cli] /Users/ningwang/GitHub/Frontend/webpack.config.js:1
import path from 'path'
^^^^^^
SyntaxError: Cannot use import statement outside a module
"devDependencies": {
"@babel/core": "^7.24.0",
"@babel/plugin-transform-react-constant-elements": "^7.23.3",
"@babel/plugin-transform-runtime": "^7.24.0",
"@babel/preset-env": "^7.24.0",
"@babel/preset-react": "^7.23.3",
"webpack": "^5.90.3",
"webpack-cli": "^5.1.4",
"webpack-dev-server": "^5.0.2"
}
Rename webpack.config.js
to webpack.config.mjs
@alexander-akait That works :) and actually I'm using it before asking. But I don't like it. One reason is that everything webpack.config.mjs
import/call/use will also need to be specific .mjs
. For example, the one you're waiting for repro: https://github.com/webpack/webpack-cli/issues/3833#issuecomment-1983305956, is cauesd by their babel.config.js
has to be renamed babel.config.mjs
.
Anyway, I'm still interested in whether we could let webpack be able to accept .js
with ESM module syntax without .mjs
? Thank you for the confirmation anyway.
Anyway, I'm still interested in whether we could let webpack be able to accept .js with ESM module syntax without .mjs?
You need to set "type": "module"
or having mjs
, it is not a webpack problem, it is how Node.js works
@alexander-akait OK, but I rarely see people using .mjs
even in some popular projects, and as I have linked above, there are currently some bugs with the kindly added new option moduleResolution: bundler
when type: module
is set. So the common way(type: module
) is buggy, and the rare way(.mjs
) is ugly.
I thought that webpack-cli needs an explicit .mjs
is because it's written in CJS. So this is not related and even this issue is completed we still have to use .mjs
to use ESM syntax for our webpack configs?
It is not related to the fact that webpack-cli is written in the commonjs format. Yes, you need "type": "module"
or mjs
if you want to use ESM, anyway you also can use babel
/etc to transpile ESM to commonjs and have the js
extension
Is your feature request related to a problem? Please describe. As node evolves, we need to change from CJS to ESM for webpack-cli.
Describe the solution you'd like
N/A
Describe alternatives you've considered
N/A Additional context
This issue originates from @alexander-akait 's feedback.