clsx: mjs causes trouble

Just wrapped it up into a plugin: webpack-modules. Importing it will fix .mjs usage in webpack.

Webpack needs this config to make .mjs work:

rules: [{
    test: /\.m?jsx?$/,
    type: 'javascript/auto',
}]

This tells webpack to treat it like everything else.

I’m not sure why webpack has done this. It’s frustrating tbh. I would much rather use .mjs but the reality is that 90% of developers won’t have webpack configured correctly, especially with tools like CRA refusing to include the above config.

@TrySound you point the issue with webpack, that should be addressed by clsx. Version 1.0.3 breaks my case. I don’t use webpack, and don’t want to run node with -r esm. .mjs works in node and browser without any transpilation. Parcel supports .mjs. I’d say, webpack should follow the node regarding .mjs resolution, because the extension is introduced because of node.

Could you point why webpack decided to change the resolution algorithm from node?

Agreed we don’t need esm since node supports ESM quite well. But the file should be .mjs. Otherwise, it can’t use export default when referred directly from the node. I think https://github.com/developit/htm is a good example of the module supporting ESM. According to https://medium.com/@giltayar/native-es-modules-in-nodejs-status-and-future-directions-part-i-ee5ea3001f71 .mjs is the only way to use ESM, and .js reserved for CJS modules, which dist/clsx.m.js is not.

It was stable – webpack changed their behavior/treatment. IIRC it was masked in CRA uproar, but CRA changed their behavior only because webpack did.

Ideally we wouldn’t need esm anywhere. For me, it’s a last resort. I mostly use it for unit testing in large codebases.

Heh. I like .esm.js ending and use it in a lot of projects. What do you think?