Module loaded twice

[dennyferra]

Summary

I'm using Next.js 13.2.4 and Experimental app dir is enabled.

I have a shared module shared.ts that is being used by app/admin/page.tsx (dynamic) as well as pages/api/admin/index.ts. I was noticing some weird behavior, like my shared module was being loaded more than once. So I simply added a console.log at the top of the shared file and ran the application in production mode. When I hit my admin page I saw one console log. Shortly after I hit the API and saw another console log. Subsequent requests didn't emit any further console logs.

So it appears that my module is being loaded twice - once for pages and once for API - I have a way to get around this (using global) - but I would like to better understand why this occurs. Code splitting/bundling? For kicks I also tried updating to Next 13.4.9 and moved my API to app/api/admin/route.ts but noticed the same behavior.

Thanks!

Additional information

No response

Example

No response

[jasontaylor137]

Does this happen in "next dev" only? I ran into something similar and it was react strict mode running useEffect more than once deliberately in dev mode.

[dennyferra]

No this happens in production as well. I've ran across the double rendering/strict mode but this is purely on the server side in prod.

This actually came up because of a pattern that was suggested by Prisma guide: https://www.prisma.io/docs/guides/other/troubleshooting-orm/help-articles/nextjs-prisma-client-dev-practices

In particular: if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma

It doesn't use global in production, so I thought the module would only be loaded once. I followed that same pattern for my shared module but production is where the strange behavior was occurring, leading me to find that the module was being loaded twice.

[rasif-sahl]

The behavior you're experiencing, where your shared module is being loaded multiple times in different parts of your Next.js application, can occur due to how Next.js handles code splitting and bundling.

Next.js employs code splitting to optimize the initial loading time of your application. It dynamically generates separate JavaScript bundles for different parts of your application based on their usage and dependencies. This allows for faster initial loading and better performance.

In the case of your shared module, if it is imported in both the app/admin/page.tsx file and the pages/api/admin/index.ts file, Next.js may generate separate JavaScript bundles for these two parts of your application. This can result in the shared module being loaded twice, once for each bundle.

To mitigate this issue, you can use dynamic imports in your Next.js application. By using dynamic imports, you can ensure that the shared module is only loaded once, even if it is imported in different parts of your application.

Here's an example of how you can use dynamic imports to import your shared module:

// app/admin/page.tsx

import dynamic from 'next/dynamic';

const SharedModule = dynamic(() => import('../path/to/shared'), { ssr: false });

function AdminPage() {
  return (
    <div>
      {/* Use the SharedModule */}
      <SharedModule />
    </div>
  );
}

export default AdminPage;

// pages/api/admin/index.ts

import { NextApiRequest, NextApiResponse } from 'next';
import dynamic from 'next/dynamic';

const SharedModule = dynamic(() => import('../../path/to/shared'), { ssr: false });

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  // Use the SharedModule
  SharedModule.someFunction();

  // ...
}

In this example, the SharedModule is imported using the dynamic function from next/dynamic. The { ssr: false } option ensures that the module is only loaded on the client side and not during server-side rendering. This way, the module will be loaded dynamically when needed, avoiding duplicate loading across different parts of your application.

By using dynamic imports, you can optimize the loading of your shared module in Next.js and avoid duplicate loading across different parts of your application.

[icyJoseph]

Hi,

This is somewhat normal, I think, at least in dev mode, as every path is compiled, the modules are loaded for that path.

Could you try, in a production build, to set a flag and skip doing work if the module has already been loaded?

Another somewhat related question I answered earlier: #51897 (comment)

[funway]

Try to add this following code in your module, you will find out the answer.

console.log('[TRACE] module initialization:', __filename, 'pid:', process.pid);
console.trace();

I think this is due to the “fake” webpack runtime. Although it also runs in the Node.js runtime, it has its own module loader.
So, besides the modules being loaded by the Node.js runtime itself, this webpack runtime will load the modules again, as long as you reference them in the App Router.