ESM in .mjs files cause a dev mode runtime error

[jaydenseric]

Bug report

Describe the bug

Importing a project ESM .mjs file (the Node.js standard file extension for ESM) in a page file causes a runtime error, but only in dev mode:

Unhandled Runtime Error
ReferenceError: module is not defined

Here is the call stack:

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Create a basic Next.js project.

2. Create a config.mjs file containing:

   export const A = 'a';

3. In pages/index.js:

   import { A } from '../config.mjs';
   
   export default function IndexPage() {
     return A;
   }

4. In Terminal, run:

   npm run dev
   

You should then see no error in Terminal, but on the client you will see the Next.js error overlay with the error described earlier.

Expected behavior

You should be able to use ESM .mjs files in your Next.js project without runtime errors in dev mode.

System information

• Version of Next.js: v9.5.5

Additional context

Other Next.js users have also encountered this issue:

#13076

[ScriptedAlchemy]

https://twitter.com/ScriptedAlchemy/status/1315424669026058240?s=20

[meglio]

In the meantime, is there any workaround to use .mjs files in the dev mode? I'm trying to introduce Next.js to an existing project, but this prevents me from doing so. Please advise.

[jerrygreen]

Am I the single one here who doesn’t understand why choose mjs over js? Imports? Already supported in NextJS without having to use mjs. WASM modules? I already experimented with this and can assure you it’s also working already. Is it top level await or import.meta.url or what?
P.S. no sarcasm btw, just wanna know

[jaydenseric]

@jerrygreen Next.js must support standard Node.js file extensions such as .mjs and .cjs without errors or bugs. If you are really interested in the design decisions behind the Node.js API for modules, read through the issues, PRs, and meeting notes of the Node.js Modules Team. Honestly, it's not worth the time for someone coming onto the scene now as there are many comments to read through; just follow the final rules as documented for the Node.js API.

Going further, Next.js should only support ESM in .js files if the project package.json contains "type": "module". If Next.js continues to refuse to adhere to Node.js standards regarding module formats I'll move to something else, or even create it myself if need be.

Already supported in NextJS without having to use mjs.

Just because Next.js has the ability to hack together webpack and Babel configs to make non standard things work due to a build step, doesn't mean it should. It's better for the ecosystem if all our tools work to common standards; e.g. you want to be able to use in a Next.js project the same ESLint config you use for linting imports in your published Node.js packages.

[jerrygreen]

Just because Next.js has the ability to hack together webpack and Babel configs to make non standard things work due to a build step, doesn't mean it should. It's better for the ecosystem if all our tools work to common standards

Oh, now I can finally see the reasoning! Yeah, I actually agree it should be supported, and less webpack hacks used: it's better to be handled by node since it does support all that too. Well, good thing Timer added this to the backlog milestone so hopefully it will be fixed sometime soon

[JacobLey]

I have recently run into this issue as well, using .js with "type":"module"

In my use case, NextJS is just a part of a larger monorepo, all written with ESM. I definitely support the comment

Just because Next.js has the ability to hack together webpack and Babel configs to make non standard things work due to a build step, doesn't mean it should. It's better for the ecosystem if all our tools work to common standards

In most cases it is great because it allows features like import/export and top-level-await, all without needing a special transpiler like Babel or Typescript (I still use Typescript, but with ES module/target, so no transpiling).
But NextJS has trouble loading some of those utility files.

That twitter link #17806 (comment) actually appears to have fixed it for me, but it would be great to see this as a first-class feature and "just work" in NextJS without extra setup.

I will say I disagree with

Next.js should only support ESM in .js files if the project package.json contains "type": "module"

While that is most "correct", that would be breaking for most usage, which is writing ESM and expect it to automagically transpile into CommonJS.

If someone is deploying NextJS on its own (e.g. via Vercel, no custom server, no monorepo...) then Babels unambiguous sourceType is plenty acceptable to me