Cannot find module error when package directory name ends with next

[athyuttamre]

Run next info (available from version 12.0.8 and up)

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:24 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T8101
Binaries:
  Node: 17.0.1
  npm: 8.1.0
  Yarn: 1.22.10
  pnpm: N/A
Relevant packages:
  next: 12.0.10
  react: 17.0.2
  react-dom: 17.0.2

What version of Next.js are you using?

12.0.10

What version of Node.js are you using?

17.0.1

What browser are you using?

Chrome

What operating system are you using?

macOS Monterey 12.0.1

How are you deploying your application?

Local

Describe the Bug

Next.js is unable to find a module in a package even though it exists. This only shows up when the parent directory's name ends with next.

I'm trying to create an npm package that other Next.js developers can import and use in their codebase.

My package is called repro, but the directory it lives in is called next. The reason I'm doing this is that I'm developing packages for multiple frameworks (so you can imagine having directories called next, remix, express, etc.). This directory then has an examples/basic directory within it which is a Next.js application. This application depends on the package via a npm install ../.., which creates a "repro": "file:../.." entry within its dependencies.

When I try to run my examples/basic Next.js application, API routes are unable to import the code from my package. Instead, they fail with a module resolution error that looks like the image below.

error - Error: Cannot find module '../../../dist/server/server.js'
Require stack:
- /Users/athyuttamre/Work/github/next-module-reproduction/next/examples/basic/.next/server/pages/api/hello.js
- /Users/athyuttamre/Work/github/next-module-reproduction/next/examples/basic/node_modules/next/dist/server/next-server.js
- /Users/athyuttamre/Work/github/next-module-reproduction/next/examples/basic/node_modules/next/dist/server/next.js
- /Users/athyuttamre/Work/github/next-module-reproduction/next/examples/basic/node_modules/next/dist/server/lib/start-server.js
- /Users/athyuttamre/Work/github/next-module-reproduction/next/examples/basic/node_modules/next/dist/cli/next-dev.js
- /Users/athyuttamre/Work/github/next-module-reproduction/next/examples/basic/node_modules/next/dist/bin/next

This happens if the parent directory is named next or has a name that ends with it, such as foo-next. If the parent directory is named something else, like foo or next-foo, this doesn't happen.

Expected Behavior

I expect the code to compile without any issues.

To Reproduce

Reproduction with steps: https://github.com/athyuttamre/next-module-reproduction

[athyuttamre]

This issue is also showing up when a package is published to npm. If the package name ends with next, Next.js is not able to resolve modules correctly. That should increase the severity of this bug in my book, since the only workaround is to change your product's name.

[balazsorban44]

Hi, I just looked into this, but already am stuck on the steps 4.

1. cd next or cd foo-next
2. npm run clean to remove the .next, node_modules, and package-lock.json files.
3. npm run dev to install node modules, compile the package using TypeScript, and run the example.
4. Navigate to http://localhost:3000/api/hello and observe the error.

None of foo, foo-next, next or next-foo produces the described error on my computer 🤔

CORRECTION

Apologies, I was looking at the URL http://localhost:3000 instead of the API route, my bad! I can actually reproduce it that way!

Thank you for the clear reproduction. 🙏

[balazsorban44]

For what it's worth, I had a similar use case when I wanted a way to work on a package with Next.js' live reload, within an example app. I came up with this solution over at next-auth: nextauthjs/next-auth#2631

(That repo is being converted into a monorepo now, for similar goals, creating framework-specific packages.)

[balazsorban44]

Having another look, I noticed a few issues:

I noticed you are using exports. You should add type: "module" to the package.json file to tell Next.js it should be consumed as an ESModule.

Furthermore, your tsconfig.json sets "module": "commonjs" which will break, even if type: "module". If you want to make a true ESM package, set that to ES2015 or something higher.

Have a look at the Node.js documentation for more context: https://nodejs.org/api/packages.html

Corporating those changes, I only needed a small additional change to get your setup working.

Somehow this line "./server": "./dist/server/index.js" breaks. changing it to "./server": "./dist/server/server.js" and running yarn clean && yarn dev, the page http://localhost:3000/api/hello loads correctly.

So there is still a high chance of a bug here, just wanted to share what I've found so far.

[balazsorban44]

The issue is likely related to this line:

next.js/packages/next/build/webpack-config.ts

Line 880 in 7be6359

/next[/\\]dist[/\\](shared|server)[/\\](?!lib[/\\](router[/\\]router|dynamic))/.test(

Poking around with it locally, I could get one of the cases working.

[athyuttamre]

Thanks for engaging!

I noticed you are using exports. You should add type: "module" to the package.json file to tell Next.js it should be consumed as an ESModule.

Furthermore, your tsconfig.json sets "module": "commonjs" which will break, even if type: "module". If you want to make a true ESM package, set that to ES2015 or something higher.

I'll consider publishing my module as ESM only, but I vaguely recall running into some issues because of that. Regardless, my expectation is that Next.js should be able to import any CommonJS module.

Somehow this line "./server": "./dist/server/index.js" breaks. changing it to "./server": "./dist/server/server.js" and running yarn clean && yarn dev, the page http://localhost:3000/api/hello loads correctly.

This is changing the semantics of the package. I do want to export server/index.ts and client/index.ts because those files will import and re-export many modules in addition to server.ts and client.ts.

The issue is likely related to this line:

That sounds plausible! It really is based on the directory name, so some Webpack code resolution settings seem like the likely culprit.

[balazsorban44]

This is changing the semantics of the package. I do want to export server/index.ts and client/index.ts because those files will import and re-export many modules in addition to server.ts and client.ts.

Understandable, it was just an observation. The bug is noted, I'm now trying to create a fix/test for this so we won't regress.

This issue is also showing up when a package is published to npm

Do you have an npm package example that also produces that issue? I'm trying to reproduce it as well.

(I created this one, but it worked: https://www.npmjs.com/package/@balazsorban/pkg-34000-next)

To be more precise, the issue will happen when next/dist/server or next/dist/shared is present. We might also need some checks for the words lib, router, and dynamic.

[athyuttamre]

Don't have an npm package handy, but I did run into it while developing my application. I'll try to make a repro.

[balazsorban44]

Yeah, I can try too, I was just curious. Thanks for reporting!

[samcx]

This is no longer happening on the latest!

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.