Cannot find module when package directory name ends with next
  • 24-Apr-2023
Lightrun Team
Author Lightrun Team
Cannot find module when package directory name ends with next

‘Cannot find module’ error when package directory name ends with ‘next’

Lightrun Team
Lightrun Team

Explanation of the problem

The issue encountered is Next.js’ inability to locate a module in a package despite its existence, but only when the parent directory’s name ends with “next”. This problem occurs while attempting to create an npm package that other Next.js developers can import and use. The package’s name is “repro”, and it resides in a directory named “next” that has an “examples/basic” subdirectory, which is a Next.js application. The application relies on the package through a “npm install ../..” command, creating a “repro”: “file:../..” entry in its dependencies.

When running the examples/basic Next.js application, API routes fail to import code from the package and generate a module resolution error, as seen in the provided error message. This error occurs only if the parent directory is named “next” or has a name that ends with “next,” such as “foo-next.” However, it does not occur if the parent directory is named something else, such as “foo” or “next-foo.”

Troubleshooting with the Lightrun Developer Observability Platform

Getting a sense of what’s actually happening inside a live application is a frustrating experience, one that relies mostly on querying and observing whatever logs were written during development.
Lightrun is a Developer Observability Platform, allowing developers to add telemetry to live applications in real-time, on-demand, and right from the IDE.

  • Instantly add logs to, set metrics in, and take snapshots of live applications
  • Insights delivered straight to your IDE or CLI
  • Works where you do: dev, QA, staging, CI/CD, and production

Start for free today

Problem solution for ‘Cannot find module’ error when package directory name ends with ‘next’

The issue with the Next.js package appears to be related to the configuration and implementation of ESM and CommonJS modules. One possible solution proposed is to adjust the package.json and tsconfig.json files to properly configure the package as an ESModule. The package.json file should have the type field set to “module” to indicate that it should be consumed as an ESModule. Meanwhile, the tsconfig.json file should set the module field to ES2015 or higher if a true ESM package is desired. The respondent notes that having the module field set to “commonjs” may still break the package, even if the type field is set to “module”.

Another respondent provided specific steps to reproduce the error, which may help in pinpointing the issue. In the steps, the respondent recommends running the npm run clean command to remove the .next, node_modules, and package-lock.json files, followed by npm run dev to install node modules, compile the package using TypeScript, and run the example. After this, navigating to http://localhost:3000/api/hello should display the error. This step-by-step approach can help to identify the specific line of code causing the problem.

Further investigation may be necessary to determine the root cause of the issue, which may be related to the Webpack code resolution settings. The respondent notes that the issue may be related to the line “./server”: “./dist/server/index.js”, and suggests that the problem may be due to the directory name, as Webpack code resolution settings are often based on directory names. This may require additional troubleshooting to find a resolution. Overall, a combination of adjusting the configuration files and further investigation may be necessary to address the issue with the Next.js package.

Other popular problems with Next.js

Problem: Error “window is not defined”.

This error occurs when a component tries to access the window object, which is only available in the browser environment, but is being executed on the server during server-side rendering.


To fix this issue, you can use the “dynamic” component from the “next/dynamic” module, which will only load the component on the client-side, where the window object is available. Here’s an example of how to use the “dynamic” component:

<code class="language-javascript">import dynamic from 'next/dynamic';

const MyComponent = dynamic(() => import('../components/MyComponent'), {
  ssr: false

export default function Home() {
  return (
      <MyComponent />

In this example, we’re importing the “MyComponent” component using the “dynamic” function and passing in the “ssr: false” option to prevent it from being rendered on the server.

Problem: Error “Module not found: Can’t resolve ‘fs'”.

This error occurs when a module tries to import the “fs” module, which is a built-in Node.js module that provides access to the file system, but is not available in the browser environment.


To fix this issue, you can add the “webpack” property to the “next.config.js” file and set the “fs” module to “empty”. Here’s an example of how to do this:

module.exports = {
  webpack: (config, { isServer }) => {
    if (!isServer) {
      config.node = {
        fs: 'empty'
    return config;

In this example, we’re checking if the code is being executed on the server or client, and setting the “fs” module to “empty” only on the client side, where it’s not needed.

Problem: Error “Module parse failed: Unexpected token”.

This error occurs when Webpack encounters an unexpected token while parsing a module, such as an unsupported syntax or a missing dependency.


To fix this issue, you can add a “resolve” property to the “next.config.js” file and set the “extensions” property to include the file extensions of the modules you’re using. Here’s an example of how to do this:

  module.exports = {
    resolve: {
       extensions: ['.ts', '.tsx', '.js', '.jsx']

In this example, we’re telling Webpack to look for modules with the “.ts”, “.tsx”, “.js”, and “.jsx” extensions, which should cover most of the popular module types used in a Next.js application. This can help resolve issues related to module parsing and ensure that all of your dependencies are properly recognized by Webpack.


A brief introduction of Next.js

Next.js is a powerful open-source web application framework built on top of Node.js that enables developers to build modern web applications with ease. It follows the concept of server-side rendering, which means that the web page’s initial rendering is done on the server and then sent to the client. This approach provides a better user experience by reducing the time to first render and improving search engine optimization. Additionally, Next.js offers a range of features such as automatic code splitting, optimized prefetching, client-side routing, and many others.

One of the key advantages of Next.js is its efficient handling of server-side rendering. By default, Next.js pre-renders every page, which can improve performance, especially on slower devices or low-bandwidth connections. The framework also allows for easy integration with popular data-fetching libraries like GraphQL and REST APIs. Furthermore, Next.js provides support for TypeScript, which enables developers to write statically-typed code, making it easier to catch type errors during development. Additionally, Next.js has a powerful file-based routing system, which allows for creating dynamic routes by mapping a directory structure to a URL. Overall, Next.js is a robust and highly customizable framework that makes it easy for developers to build scalable and high-performing web applications.

Most popular use cases for Next.js

  1. Server-side rendering and static site generation: Next.js allows developers to build applications that support server-side rendering (SSR) and static site generation (SSG) out of the box. This means that the server can pre-render pages and send them to the client as HTML, allowing for faster initial load times and improved SEO. To enable SSR or SSG, developers can use Next.js’s built-in functions such as getServerSideProps() or getStaticProps() to fetch data and generate pages at build time or request time.

Example code block for using getStaticProps():

export async function getStaticProps() {
  // Fetch data from an API or database
  const res = await fetch('');
  const data = await res.json();

  // Return the data as props
  return {
    props: {
  1. Automatic code splitting: Next.js automatically splits code into smaller chunks based on the routes of the application. This means that users only download the code they need for the current page, resulting in faster load times and better performance. Developers can also manually split code using dynamic imports and import statements with webpack’s code splitting features.

Example code block for manual code splitting:


import dynamic from 'next/dynamic';

const ComponentWithHeavyDependencies = dynamic(
  () => import('../components/ComponentWithHeavyDependencies'),
  { ssr: false }

function HomePage() {
  return (
      <ComponentWithHeavyDependencies />
  1. Fullstack development: Next.js can be used for fullstack development, allowing developers to build both the client and server-side of an application using a single language and framework. With features like API routes and serverless functions, developers can easily create backend logic to power their applications. Next.js also integrates with popular databases, such as MongoDB and PostgreSQL, and has support for authentication and authorization libraries like Passport.js and NextAuth.js.

Example code block for an API route:


export default function handler(req, res) {
  const data = { name: 'John', age: 30 };

It’s Really not that Complicated.

You can actually understand what’s going on inside your live applications. It’s a registration form away.

Get Lightrun

Lets Talk!

Looking for more information about Lightrun and debugging?
We’d love to hear from you!
Drop us a line and we’ll get back to you shortly.

By submitting this form, I agree to Lightrun’s Privacy Policy and Terms of Use.