mjs files get imported as static files

[jgoux]

Hello,

Here is a repro :

import graphql, { parse, buildASTSchema, buildClientSchema } from 'graphql'
console.log(graphql, parse, buildASTSchema, buildClientSchema)
// ouput : /static/media/index.497f5ee2.mjs undefined undefined undefined

Excluding the .mjs extension from the file-loader fix the issue.

[gaearon]

I am so lost. 😥

Can somebody who has a stake in getting mjs working with Create React App (e.g. Apollo, graphql package, etc) please comment here and suggest the proposed plan for how we should be interpreting it?

cc @lencioni @jgoux @hobochild @leebyron @jdalton @jbaxleyiii @jaydenseric who participated in earlier threads

So far mjs has created nothing but churn for us and our users, and I'm still not sure what are the intended benefits of this shift at this point time. I empathize with the desire to be ESM-compatible when Node removes the flag, but I'm also confused about what we should be doing right now in Create React App.

Our constraints are:

• we need to support both Jest and webpack
• Jest probably won't have native ESM support for a while
• we can't afford to completely break when a library releases an mjs version side by side
• (?) I guess it's reasonable that libraries shipping only mjs won't work in Jest?

We've intentionally tried to disable mjs support, as discussed in #4085 (comment). But apparently this is still not enough because graphql specifies mjs as a module field thus still bringing it in even though we've decided against supporting it. So we have no other option than to support it, then?

[jaydenseric]

because graphql specifies mjs as a module field thus still bringing it in even though we've decided against supporting it. So we have no other option than to support it, then?

Yes, at least when bundling dependencies in node_modules. You can decide however not to support .mjs in project files, that is the level of support Next.js has.

Out of the box Webpack handles .mjs in the module field just fine, you run into problems when you customise the resolve.extensions field and explicitly leave out (or misorder) .mjs.

See jaydenseric/apollo-upload-client#118 (comment)

[gaearon]

Does #5258 look like the right fix for you?

[gaearon]

Is there a set of packages that we can test our support on? To verify we don't keep breaking this in every release.

[Timer]

#5258 should get us back on track to supporting what will be "properly" setup packages in a Node & web world.
graphql is probably the best package to test with: it supports CommonJS and ESM, properly toggling between ESM or CommonJS based on what the Node environment supports.

Can someone with more knowledge in this area please confirm this is true?

[jaydenseric]

The CRA config is a little more complex than I'm used to… does CRA attempt to transpile all of node_modules? If so, does it leave out the CJS/ESM transforms for Webpack to handle? Babel transpiling the ESM in an .mjs file might mess with Webpack's ability to do proper CJS interop when bundling.

[Timer]

CRA compiles all of node_modules, yes. We leave out the ESM => CJS transform so webpack handles it.

[jdalton]

@Timer

graphql is probably the best package to test with: it supports CommonJS and ESM, properly toggling between ESM or CommonJS based on what the Node environment supports.

It's still pretty hard to get things right with the current state of things. For example, even graphql has issues working with --experimental-modules with mixed CJS and ESM use. It'd be helpful to avoid any solution that makes .mjs viral (requiring consumers, or deps of deps to be renamed to .mjs to get things bundled properly).

Projects like Babel 7, webpack 4, and esm restrict .mjs use or implement more-strict rules when handling experimental .mjs files. However, Babel and webpack can be configured to handle .mjs in less-strict ways. I think complications may come from webpack enforcing its javascript/esm for .mjs by default, instead of javascript/auto for the module type.

[jaydenseric]

.mjs intentionally sends a very strong signal that the mode is to be esm, and for how CJS may be imported. No one should be putting anything other than correct ESM in an .mjs file, and it is a grave mistake to facilitate or encourage misuse.

It is far preferable that a bundling error throws so people can fix (and learn about) their flawed .mjs or stop using it, rather than mask issues and then the .mjs won't run natively in Node.js or in other tools that do fairly assume that .mjs means ESM.

@jdalton The graphql issue you are talking about is not relevant to this issue.