Clean output directory before build to prevent recursive bundling

[szcharlesji]

This PR fixes the bug where subsequent builds would cause the .open-next output directory to be recursively bundled within itself, leading to exponential growth in bundle size and slow build times.

What the issue is

I used OpenNext to build my Nextjs app with Prisma a couple times until I got an error:

Failed to compile.

Error: ENAMETOOLONG: name too long, readlink 

.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/app/generated/prisma/schema.prisma

1. If I do rm -rf .next .open-next then npx --yes @opennextjs/aws@latest build first for a clean build, there is no issue.
2. Run a Second Build (Without Cleaning)
   Now, run the build command again without deleting the .open-next directory. This will trigger the bug.

npx --yes @opennextjs/aws@latest build

3. I then checked the Nextjs traces:

• .next/server/app/page.js.nft.json (for the root App Router page)
• .next/server/pages/api/some-route.js.nft.json (for a Pages Router API route)

It will contain a JSON object with a files array. This array lists all the file paths that Next.js determined are dependencies.

Search for the string .open-next inside this file.

On the first (clean) build, I will NOT see any paths containing .open-next. The paths will correctly point to the source code or node_modules, like this:

{
  "version": 1,
  "files": [
    "../../node_modules/some-package/index.js",
    "../../prisma/schema.prisma"
  ]
}

On the second build, I WILL see paths that point into the previous build's output directory:

{
  "version": 1,
  "files": [
    "../../node_modules/some-package/index.js",
    "../../prisma/schema.prisma",
    "../../.open-next/server-functions/default/prisma/schema.prisma"
  ]
}

This issue is not exclusive to Prisma. It can occur with any library or tool that requires access to local source code files at runtime and is used in server-side code.

The key conditions are:

• A library's runtime code needs to read a file from the project's source tree (e.g., a schema, a config file, or content files).
• server-side code (like a Server Action or API route) imports and uses that library, causing Next.js to trace those local files as dependencies.

The Simple Fix

The core of the problem was a feedback loop in the build process.
Before the Fix (Incorrect Order):

1. next build would run first.
2. The build process would scan the project for dependencies and find files in the old .open-next directory from the previous run.
3. The .open-next directory would then be deleted.
4. The new build would be created using the incorrect dependency list, causing a recursive copy.

After the Fix (Correct Order):

1. The .open-next directory is deleted first, ensuring a clean slate.
2. next build runs, scanning a clean project and generating a correct list of dependencies.
3. The new build is created without any recursive artifacts.

While it is possible to fix it with this flag in next.config.ts below. It is still a workaround and adds config debt so I think changing the building step order is a more ideal fix.

const nextConfig: NextConfig = {  
  // This tells Next.js's file tracer to ignore all files and folders
  // inside the .open-next directory.
  outputFileTracingExcludes: [".open-next/**/*"],
};

#951
Issue I Submitted
Reproduction Repo

[changeset-bot]

⚠️ No Changeset found

Latest commit: e1aa950

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[khuezy]

Thanks for the investigation and fix!