-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
Comments
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 |
It only occurs in
|
Please make sure to verify |
I can verify that the issue is present in |
I can reproduce this in chrome; it seems to be an issue on the server side rather than browser |
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.
|
For me this was caused by Sentry not being supported with Turbo. I added a conditional check before loading sentry in // ./next.config.js
if (!process.env.TURBOPACK) {
module.exports = withSentryConfig(module.exports, { ... });
} And in my // ./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). |
Can confirm that this was also the issue on mine. I already made that change to |
@richardasymmetric I followed your steps but I don't get an error:
Would be great if anyone else could also share a reproduction. |
@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 |
Yes, I see the error now 👍 |
@mischnic thank you so much for diagnosing and fixing this! @AhmedBaset Looking at the fix, it appears you could add // next.config.js
const config = {
experimental: {
serverComponentsExternalPackages: [`require-in-the-middle`],
},
};
export default config; |
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`).
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`).
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.
cp .env.development.local.sample .env.development.local
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
,CLERK_SECRET_KEY
, andSENTRY_DSN
yarn dev
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:
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
The text was updated successfully, but these errors were encountered: