-
Notifications
You must be signed in to change notification settings - Fork 27.7k
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
[NEXT-1032] A Node.js API is used (process.turbopack at line: 47) which is not supported in the Edge Runtime. #48302
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
I have the same error with next-auth |
I think I'm getting something related when I add the next-auth/middleware. middleware.ts
Error:
Can we disable the edge runtime completely when building a standalone app? |
I saw that issue as well in GCP logs on builds so it could definitely be related. |
I looks like the As a workaround, I've added the following line to the Dockerfile: COPY --from=builder --chown=nextjs:nodejs /app/.next/server/edge-chunks ./.next/server/edge-chunks This handles the I'm guessing that these WASM chunks are related to the |
@GeorgEchterling THANKS! It's working now |
Having the same issue with the |
Same error here using next-intl/middleware.
@Defrosted thanks, your workaround was useful to deploy to amplify hosting (using an amplify.yml). Although AppDir is working fine on amplify hosting I wonder about the performance using SST, the cold start of almost 10seconds is a bit annoying. can you tell me if its better on SST? |
10 seconds sounds quite extreme. Not sure if SST would be able to help with that if the underlying cause is somewhere else. My guess would be that Amplify uses a similar infrastructure with Lambdas under the hood. The nice side with SST is that you're in control of the infrastructure. I haven't personally seen that high cold starts so far. |
the same for me |
I confirm that @Defrosted comment mentioning a PR is fixing this, works fine in "13.3.5-canary.5" to me |
After upgrade to nextjs 13.4.0 (from 13.3.4) Vercel started to fail at build time with a similar message. Vercel is configured to use Node 18.x The example repo is: https://github.com/belgattitude/nextjs-monorepo-example (branch main) (no-app-dir) The ci passes (build on node works) on main, vercel just started to break after upgrade. If you want to try on vercel, you'll have to add ENABLE_EXPERIMENTAL_COREPACK=1 in the vercel env. Open to help if needed |
Looks like this has been fixed as of version 13.4.7. The |
Closing this as it's very old and probably fixed, feel free to open a new issue |
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. |
Verify canary release
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:43 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8112 Binaries: Node: 19.7.0 npm: 9.5.0 Yarn: 3.5.0 pnpm: N/A Relevant packages: next: 13.3.0 eslint-config-next: N/A react: 18.2.0 react-dom: 18.2.0
Which area(s) of Next.js are affected? (leave empty if unsure)
Middleware / Edge (API routes, runtime)
Link to the code that reproduces this issue
https://github.com/TrevorThomp/nextjs-auth-repro
To Reproduce
Describe the Bug
When building the Next application through
![Error](https://user-images.githubusercontent.com/46389554/231538934-4c1751bd-3ff1-4134-b757-e621893968ad.PNG)
next build
the following output occurs and will fail my builds in GCP:I raised this issue with Nextjs-Auth0 and they directed me back to here
auth0/nextjs-auth0#1152
The changes that started throwing this error was in the 13.3.0 release:
#47715
d71cbe9#diff-88cc5222d0ce7e563716eee434a1045d101b0043afd2450d66c9eb1ca4ac5cbb
Expected Behavior
Middleware with auth works as expected.
Which browser are you using? (if relevant)
N/A
How are you deploying your application? (if relevant)
N/A
NEXT-1032
The text was updated successfully, but these errors were encountered: