Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NextJs+Turbo+ClerkJs+sentry+HMR causes Module was instantiated ... but ... is not available. It might have been deleted in an HMR update. #70424

Closed
richardasymmetric opened this issue Sep 24, 2024 · 15 comments · Fixed by #70922
Labels
bug Issue was opened via the bug report template. Developer Experience Issues related to Next.js logs, Error overlay, etc. linear: turbopack Confirmed issue that is tracked by the Turbopack team. Turbopack Related to Turbopack with Next.js.

Comments

@richardasymmetric
Copy link

richardasymmetric commented Sep 24, 2024

Link to the code that reproduces this issue

https://github.com/richardasymmetric/next-clerk-hmr-error

To Reproduce

Sorry for the convoluted reproduction, I'm actually not sure which project (nextjs or clerkjs or turbopack edit or sentry) that I should be reporting this to. I have previously encountered this issue but wasn't sure what caused it since it was a large project, but I started a fresh project today and ran into this issue once I'd added clerkjs into the project, and so it will require a clerk key to run the reproduction.

edit However, it appears that there's some interaction with sentry going on.

  1. Clone the repo
  2. Create the env: cp .env.development.local.sample .env.development.local
  3. Fill in NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY, CLERK_SECRET_KEY, and SENTRY_DSN
  4. Run yarn dev
  5. Go to localhost:3000/sign-in
  6. Now, you can either edit the .env.development.local directly, or click the "trigger" button that will edit the .env file directly
  7. This causes the hmr to trigger causing an HMR error.

I usually reproducing by editing code, but haven't found a consistent way to trigger it. It's a real show stopper for me when using --turbo and I've had to stop using it for the last few months because of this issue.

Current vs. Expected behavior

Expected behaviour: the hmr reloads and continues as expected

Actual behaviour:

Error: Module [project]/node_modules/next/dist/esm/client/components/error-boundary.js [app-ssr] (ecmascript) was instantiated because it was required from module [project]/node_modules/next/dist/esm/build/templates/app-page.js?page=/sign-in/[[...sign-in]]/page { COMPONENT_0 => "[project]/app/layout.tsx [app-rsc] (ecmascript, Next.js server component)", COMPONENT_1 => "[project]/node_modules/next/dist/client/components/not-found-error.js [app-rsc] (ecmascript, Next.js server component)", COMPONENT_2 => "[project]/app/sign-in/[[...sign-in]]/page.tsx [app-rsc] (ecmascript, Next.js server component)", METADATA_3 => "[project]/app/favicon.ico.mjs { IMAGE => \"[project]/app/favicon.ico [app-rsc] (static)\" } [app-rsc] (structured image object, ecmascript)" } [app-rsc] (ecmascript) <locals>, but the module factory is not available. It might have been deleted in an HMR update.
    at instantiateModule ([project]/.next/server/chunks/ssr/[turbopack]_runtime.js:492:15)
    at getOrInstantiateModuleFromParent ([project]/.next/server/chunks/ssr/[turbopack]_runtime.js:572:12)
    at commonJsRequire ([project]/.next/server/chunks/ssr/[turbopack]_runtime.js:136:20)
    at require ([project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:39:19477)
    at [project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:89291
    at eo ([project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:89476)
    at [project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:91705
    at Object._fromJSON ([project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:92261)
    at JSON.parse (<anonymous>)
    at eu ([project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:89970)
    at en ([project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:89038)
    at [project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:96196
    at [project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:96213
    at [project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:96246
    at [project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:96263
    at t ([project]/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:96486) {
  page: '/sign-in'
}

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #41-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug  2 20:41:06 UTC 2024
  Available memory (MB): 32038
  Available CPU cores: 16
Binaries:
  Node: 20.17.0
  npm: 
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.13 // Latest available version is detected (14.2.13).
  eslint-config-next: 14.2.13
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Developer Experience, Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

I can reproduce this in next@15.0.0-canary.166

My current hypothesis for this is that there might be multiple versions of either react or next via dependencies, but I'm not certain

@richardasymmetric richardasymmetric added the bug Issue was opened via the bug report template. label Sep 24, 2024
@github-actions github-actions bot added Developer Experience Issues related to Next.js logs, Error overlay, etc. Turbopack Related to Turbopack with Next.js. labels Sep 24, 2024
@jeiea
Copy link

jeiea commented Sep 26, 2024

I encountered this on macOS node 22, next 14.2.13 too.

This happened in a situation where I changed the component source, not the .env file.

@richardasymmetric
Copy link
Author

I encountered this on macOS node 22, next 14.2.13 too.

This happened in a situation where I changed the component source, not the .env file.

Are you able to make a better reproduction than I was using the source editing? I wasn't consistently able to do it, but once it triggered, the only way to recover was to restart the next dev server.

@AhmedBaset
Copy link
Contributor

It only occurs in next dev --turbo but not with webpack

Unhandled Runtime Error

Error: Module [project]/node_modules/.pnpm/next@14.2.5_@playwright+test@1.42.1_react-dom@18.3.0-canary-14898b6a9-20240318_react@18.3.0-c_msqctw3noddsuhsaahy6syd2fy/node_modules/next/dist/compiled/react/jsx-dev-runtime.js [app-client] (ecmascript) was instantiated because it was required from module [project]/src/components/providers.tsx [app-client] (ecmascript), but the module factory is not available. It might have been deleted in an HMR update.

Source

src/components/providers.tsx (0:0) @ [project]/src/components/providers.tsx [app-client] (ecmascript)/<

  1 | "use client";
  2 |
  3 | import { DirectionProvider } from "@radix-ui/react-direction";

@timneutkens
Copy link
Member

Please make sure to verify next@canary first (as per the issue template), thanks! 🙏

@richardasymmetric
Copy link
Author

Please make sure to verify next@canary first (as per the issue template), thanks! 🙏

I can verify that the issue is present in next@canary

@richardasymmetric
Copy link
Author

richardasymmetric commented Oct 1, 2024

It only occurs in next dev --turbo but not with webpack

And in Firefox only not Chromium-based

I can reproduce this in chrome; it seems to be an issue on the server side rather than browser

@nathanlambert
Copy link

I'm also seeing it on the most recent next canary / react RCs.

I couldn't come up with consistent replication instructions. Sometimes editing/saving files results in successfully applied HMR and then other times those same changes will trigger the same state as OP. I get the same error in an incog window & other browsers, so I also believe it's server-related. Further HMR updates all fail and the only way to fix it is to kill the server and restart it.

Error: Module [project]/src/app/global-error.tsx [app-ssr] (ecmascript) was instantiated because it was required from module [project]/node_modules/next/dist/esm/build/templates/app-page.js?page=/[network]/[pairAddress]/page { GLOBAL_ERROR_MODULE => "[project]/src/app/global-error.tsx [app-rsc] (ecmascript, Next.js server component)", MODULE_0 => "[project]/src/app/layout.tsx [app-rsc] (ecmascript, Next.js server component)", MODULE_1 => "[project]/node_modules/next/dist/client/components/not-found-error.js [app-rsc] (ecmascript, Next.js server component)", MODULE_2 => "[project]/src/app/[network]/[pairAddress]/page.tsx [app-rsc] (ecmascript, Next.js server component)" } [app-rsc] (ecmascript) <locals>, but the module factory is not available. It might have been deleted in an HMR update.
    at instantiateModule (file:///.../.next/server/chunks/ssr/[turbopack]_runtime.js:551:15)
    at getOrInstantiateModuleFromParent (file:///.../.next/server/chunks/ssr/[turbopack]_runtime.js:636:12)
    at commonJsRequire (file:///.../.next/server/chunks/ssr/[turbopack]_runtime.js:147:20)
    at require (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:158:75967)
    at initializeModuleChunk (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:49:25105)
    at getOutlinedModel (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:49:28814)
    at <unknown> (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:49:33365)
    at ResponseInstance._fromJSON (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:49:33456)
    at JSON.parse (<anonymous>)
    at initializeModelChunk (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:49:24504)
    at resolveModelChunk (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:49:23879)
    at <unknown> (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:49:49088)
    at progress (file:///.../node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:49:49190)

@LonJonn
Copy link

LonJonn commented Oct 3, 2024

For me this was caused by Sentry not being supported with Turbo.

I added a conditional check before loading sentry in next.config.js:

// ./next.config.js
if (!process.env.TURBOPACK) {
  module.exports = withSentryConfig(module.exports, { ... });
}

And in my instrumentation.ts:

// ./src/instrumentation.ts
export async function register() {
  if (process.env.TURBOPACK) {
    return;
  }

  if (process.env.NEXT_RUNTIME === "nodejs") {
    await import("../sentry.server.config");
  }

  if (process.env.NEXT_RUNTIME === "edge") {
    await import("../sentry.edge.config");
  }
}

export const onRequestError = Sentry.captureRequestError;

Hopefully this helps someone.

@richardasymmetric
Copy link
Author

For me this was caused by Sentry not being supported with Turbo.

I added a conditional check before loading sentry in next.config.js:

// ./next.config.js
if (!process.env.TURBOPACK) {
  module.exports = withSentryConfig(module.exports, { ... });
}

And in my instrumentation.ts:

// ./src/instrumentation.ts
export async function register() {
  if (process.env.TURBOPACK) {
    return;
  }

  if (process.env.NEXT_RUNTIME === "nodejs") {
    await import("../sentry.server.config");
  }

  if (process.env.NEXT_RUNTIME === "edge") {
    await import("../sentry.edge.config");
  }
}

export const onRequestError = Sentry.captureRequestError;

Hopefully this helps someone.

Interestingly, this does seem to fix the issue on my reproduction. However, I still can't explain why it only started happening after added Clerk into the project (I think that I already had Sentry set up before I added Clerk).

@nathanlambert
Copy link

Can confirm that this was also the issue on mine. I already made that change to next.config.js but didn't think to update instrumentation.ts. Thank you!

@mischnic
Copy link
Contributor

mischnic commented Oct 4, 2024

@richardasymmetric I followed your steps but I don't get an error:

Would be great if anyone else could also share a reproduction.

@richardasymmetric
Copy link
Author

@mischnic I cloned your repo and was still able to reproduce it on a different machine. I think my repro instructions need updating though. It appears that the SENTRY_DSN variable also needs filling in; if I leave it blank I'm not able to trigger the bug. I'll update my original post too

@richardasymmetric richardasymmetric changed the title NextJs+Turbo+ClerkJs+HMR causes Module was instantiated ... but ... is not available. It might have been deleted in an HMR update. NextJs+Turbo+ClerkJs+sentry+HMR causes Module was instantiated ... but ... is not available. It might have been deleted in an HMR update. Oct 4, 2024
@mischnic
Copy link
Contributor

mischnic commented Oct 7, 2024

Yes, I see the error now 👍

@github-actions github-actions bot added the linear: turbopack Confirmed issue that is tracked by the Turbopack team. label Oct 7, 2024
@ijjk ijjk closed this as completed in 37ea26b Oct 7, 2024
@AhmedBaset
Copy link
Contributor

Will this be backported to 14.x?

/cc @mischnic @ijjk

@richardasymmetric
Copy link
Author

@mischnic thank you so much for diagnosing and fixing this!

@AhmedBaset Looking at the fix, it appears you could add require-in-the-middle to the serverComponentsExternalPackages config.:

// next.config.js
const config = {
 experimental: {
    serverComponentsExternalPackages: [`require-in-the-middle`],
  },
};
export default config;

kdy1 pushed a commit that referenced this issue Oct 10, 2024
Closes PACK-3288
Closes #70424

Sentry uses `open-telemetry`, which uses `require-in-the-middle` which:
- overrides the global `Module.prototype.require`, even when bundled
- reads `require.cache` which when bundled is Turbopack's registry (not
the outer Node.js one)


Because of this, `require-in-the-middle` is broken/results in a broken
environment when it's bundled (e.g. via `instrumentation.js`).
kdy1 pushed a commit that referenced this issue Oct 10, 2024
Closes PACK-3288
Closes #70424

Sentry uses `open-telemetry`, which uses `require-in-the-middle` which:
- overrides the global `Module.prototype.require`, even when bundled
- reads `require.cache` which when bundled is Turbopack's registry (not
the outer Node.js one)


Because of this, `require-in-the-middle` is broken/results in a broken
environment when it's bundled (e.g. via `instrumentation.js`).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue was opened via the bug report template. Developer Experience Issues related to Next.js logs, Error overlay, etc. linear: turbopack Confirmed issue that is tracked by the Turbopack team. Turbopack Related to Turbopack with Next.js.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants