ESM in .mjs files cause a dev mode runtime error

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:

https://github.com/vercel/next.js/discussions/13076

[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 https://github.com/vercel/next.js/issues/17806#issuecomment-707321843 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

[ScriptedAlchemy]

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