[NEXT-1032] A Node.js API is used (process.turbopack at line: 47) which is not supported in the Edge Runtime.

[TrevorThomp]

Verify canary release

• I verified that the issue exists in the latest Next.js 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

# Make sure you are on latest Yarn version (>2.0.0).
yarn set version stable

# Install dependencies specified in package.json
yarn install

# Build the application
yarn build

# Build Docker container
yarn docker:build

Describe the Bug

When building the Next application through 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

[semy]

I have the same error with next-auth

[eblanchette]

I think I'm getting something related when I add the next-auth/middleware.

middleware.ts

export { default } from "next-auth/middleware";
export const config = { matcher: ["/admin/:path*", "/api/:path*"] };

Error:

[Error: ENOENT: no such file or directory, open '/app/apps/console/.next/server/edge-chunks/wasm_ef4866ecae192fd87727067cf2c0c0cf9fb8b020.wasm']

Can we disable the edge runtime completely when building a standalone app?

[TrevorThomp]

I think I'm getting something related when I add the next-auth/middleware.

middleware.ts

export { default } from "next-auth/middleware";
export const config = { matcher: ["/admin/:path*", "/api/:path*"] };

Error:

[Error: ENOENT: no such file or directory, open '/app/apps/console/.next/server/edge-chunks/wasm_ef4866ecae192fd87727067cf2c0c0cf9fb8b020.wasm']

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.

[GeorgEchterling]

I think I'm getting something related when I add the next-auth/middleware.

middleware.ts

export { default } from "next-auth/middleware";
export const config = { matcher: ["/admin/:path*", "/api/:path*"] };

Error:

[Error: ENOENT: no such file or directory, open '/app/apps/console/.next/server/edge-chunks/wasm_ef4866ecae192fd87727067cf2c0c0cf9fb8b020.wasm']

Can we disable the edge runtime completely when building a standalone app?

I looks like the edge-chunks directory doesn't get generated for the standalone build. It is generated at .next/server/edge-chunks, but not at .next/standalone/.next/server/edge-chunks, just like the static directory.

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 edge-chunks directory in the same way as the static Directory in the Docker example. It removes the [Error: ENOENT: no such file or directory, open '/app/apps/console/.next/server/edge-chunks/wasm_ef4866ecae192fd87727067cf2c0c0cf9fb8b020.wasm'] runtime error.

I'm guessing that these WASM chunks are related to the image-response stuff, which is meant to be removed during tree shaking. So this is only a workaround, not an actual fix.

[eblanchette]

@GeorgEchterling THANKS! It's working now

[Defrosted]

Having the same issue with the edge-chunks directory not being copied over, but I'm using SST and Open Next to build. Was able to solve this for now by modifying my next build script to be next build && cp -r .next/server/edge-chunks .next/standalone/.next/server/edge-chunks.

[abepuentes]

Same error here using next-intl/middleware.

import createMiddleware from "next-intl/middleware";

export default createMiddleware({
  locales: ["en", "es"],
  defaultLocale: "en",
});

export const config = {
  // Skip all paths that should not be internationalized
  matcher: ["/((?!_next|.*\\..*).*)"],
};

@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?

[Defrosted]

Same error here using next-intl/middleware.

import createMiddleware from "next-intl/middleware";

export default createMiddleware({
  locales: ["en", "es"],
  defaultLocale: "en",
});

export const config = {
  // Skip all paths that should not be internationalized
  matcher: ["/((?!_next|.*\\..*).*)"],
};

@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.

[Kiborgik]

the same for me

[Defrosted]

Sharing this here as well: There was a discussion in #48638 regarding this, and there's now PR #48723 that attempts to fix this to my understanding.

[CKGrafico]

I confirm that @Defrosted comment mentioning a PR is fixing this, works fine in "13.3.5-canary.5" to me

[belgattitude]

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

[GeorgEchterling]

Looks like this has been fixed as of version 13.4.7. The process.turbopack warning no longer appears and the edge-chunks directory is no longer necessary.

[ForsakenHarmony]

Closing this as it's very old and probably fixed, feel free to open a new issue

[github-actions]

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.