Module not found: Can't resolve 'builtin-modules'

• mdx-bundler version: 3.1.2
• node version: 14.15.4
• yarn version: 1.22.10
• next version: 10.1.3 & 10.0.9

Relevant code or config

// config for 10.1.3
module.exports = {
  future: {
    webpack5: true,
  },
  reactStrictMode: true,
  webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
    if (!isServer) {
      // https://github.com/vercel/next.js/issues/7755
      config.resolve = {
        ...config.resolve,
        fallback: {
          ...config.resolve.fallback,
          // Don't load this on the client.
          fs: false,
        },
      }
    }

    return config
  },
}

// config for 10.0.9
module.exports = {
  reactStrictMode: true,
  webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
    if (!isServer) {
      // https://github.com/vercel/next.js/issues/7755
      config.node = {
        // Don't load this on the client.
        fs: 'empty',
      }
    }

    return config
  },
}

What you did:

Following along with the documentation and after installing mdx-bundler and trying to run the dev sever for next I get the below output. The other screen shot is the output from executing yarn build I get the same using either version and configuration of next.

What happened:

Reproduction repository:

https://github.com/rockchalkwushock/codybrunner.dev/pull/84

Problem description:

It seems as though if running either webpack@4 or opting in for webpack@5 in next there is an issue with the resolving of esm imports.

[rockchalkwushock]

@IanMitchell another solution (although I would not recommend it) is to do the following in your next.config.js

module.exports = {
  future: {
    // Opt-in to webpack@5
    webpack5: true,
  },
  reactStrictMode: true,
  webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
    if (!isServer) {
      // https://github.com/vercel/next.js/issues/7755
      config.resolve = {
        ...config.resolve,
        fallback: {
          ...config.resolve.fallback,
          child_process: false,
          fs: false,
          'builtin-modules': false,
          worker_threads: false,
        },
      }
    }

    return config
  },
}

After a lot of reading this afternoon the underlying problem is that somewhere we are accidentally shipping node based code in the client bundle. I found the following resource from Vercel for seeing what is bundled for the client. I haven’t begun using it yet to try and debug where I am accidentally shipping those node packages yet.

[rockchalkwushock]

@IanMitchell sorry just now seeing this.

I do believe I figured out what the problem is surrounding that error message. In my project all third-party service code lives in lib/ and those files are export from the index.ts like so:

export * from './service'

The service’s code is then imported as:

import { getMDXFiles, prepareMDX } from '@lib'

So the mdx service was exported like that and whenever I added another service and exported it in the same manner this error message would arise: Module not found: Can't resolve 'builtin-modules'

// No bueno
export * from './mdx'
export * from './spotify'

To fix this I simply removed the export * from './mdx' and changed the import for that service to be:

import { getMDXFIles, prepareMDX } from '../lib/mdx'

I ran into a similar issue when using firebase-admin and stumbled upon a note I left myself months ago about…at least why this was an issue with firebase-admin:

// pages/api/views/[...slug].ts

// You cannot use the @lib alias here and export * from './firebase' from the lib directory.
// The reason being that 'firebase-admin' is then being made available in the
// client-side code and this is a node based package. Shit gets hairy fast!
// This took like 30 minutes to figure out what was going wrong 🤦🏻‍♂️
import { getPostViews, updatePostViews } from '../../../lib/firebase'

...

For further reference it seems as though this is a webpack bug that was solved some time ago (not sure what release it was packaged in). next is using webpack@4.44.1 I am yet to figure out which version of webpack@5 is being used but you can see here were they switch the loading if you opt-in.

My assumption is that not mdx-bundler but xdm || esbuild (the more likely culprit) has some internal code that is clashing with the other modules when exporting and webpack no likey. My understanding of the ESM import/exports is not the greatest, although I did see @kentcdodds released a post recently on this that I need to take the time to read.

Hope this helps you out 🎉 🥂