#nextjs

Ryu Hi Asuileman, That error sounds like it may not be coming from the normal Vercel Project Settings → Domains flow, because a Vercel project is not generally limited to only one custom domain on Hobby. I’d first check where you are adding it: Vercel Dashboard → your project → Settings → Domains Then try adding the domains separately, for example: example.com www.example.com If the dashboard says you cannot add more than one domain but the domain does not appear, check whether the domain is already attached somewhere else in the same team: vercel domains ls --limit 100 vercel domains inspect your

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Amy Egan Where you able to get it solved?

Binome Agency Update: I recreated the Vercel project from scratch (same GitHub repo) and the error disappeared for 2 consecutive builds — got further into the pipeline (failed later on missing env vars, which I then fixed). However, the exact same ENOENT export-detail.json error just reappeared on a 3rd build, with the exact same code/config as the 2 successful ones. I also added an explicit "framework": "nextjs" to vercel.json as suggested elsewhere, no change. This strongly suggests the issue is intermittent/random on Vercel's build infrastructure itself, not tied to any project-specific configuration. Wo

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Ryu Hi Hero, I’d first separate “Safari is slow to get the document” from “Safari gets the document quickly but renders a blank page for a while.” A quick way to check is to run this in Safari’s console after a slow load, then compare it with Chrome on the same iPhone: const n = performance.getEntriesByType("navigation")[0]; console.table({ dns: Math.round(n.domainLookupEnd - n.domainLookupStart), connect: Math.round(n.connectEnd - n.connectStart), tls: Math.round(n.requestStart - n.secureConnectionStart), ttfb: Math.round(n.responseStart - n.requestStart), download: Math.round(n.responseEnd - n.r

Ryu Hi Anurag, I’d check whether getHoroscope() is being cached at request time rather than during prerender/static shell generation. The local vs Vercel difference can make this confusing: locally you usually have one long-running server process, so an in-memory use cache entry is easy to hit. On Vercel, if that dynamic route is evaluated at runtime, requests can land on different function instances/regions, so the default in-memory use cache entry may not be reused the same way. That would also explain why getMenu() works while getHoroscope(day, sign) does not: the menu may be part of a more sta

Ryu Hi Kishor, For IIS, I’d separate the problem into two parts: Turborepo build orchestration and how each Next.js app is served. Turborepo itself is not something you “deploy” to IIS as one running app. Usually you build each app separately, and the shared packages from packages/ are bundled/compiled into whichever app depends on them. From the monorepo root, the basic shape is usually: npm install npx turbo run build --filter=app-1 npx turbo run build --filter=app-2 npx turbo run build --filter=app-3 Then for each app you need to decide whether it is static or server-rendered. If an app is full

Ryu Hi Devansh, If those Sentry events cluster around deploy times, I’d treat this as version skew first. With dynamic(() => import(...), { ssr: false }), the browser may not request that CSS/JS chunk until later. If the user loaded HTML/JS from an older deployment, then a new production deployment goes live, that old client can later try to fetch a chunk URL that no longer exists on the deployment it is being routed to. That usually shows up as: Loading CSS chunk failed /_next/static/css/<hash>.css A good way to confirm is to check the failed asset request in Sentry or browser devtools: status: 4

Tianen Pang check this one github.com/vercel/next.js/issues/89764#issuecomment-3928272828 for temp fix

ADALIGO The error comes from tooling mismatch not from you Luknuts56, just downgrade ESLint and you’re good 👍

Ryu Hi Luknuts56, This one looks like a tooling-version mismatch, not a problem with your loading.tsx file. Your package.json has: "eslint": "10.0.3", "eslint-config-next": "^16.1.7" and the stack trace is failing inside eslint-plugin-react while loading the react/display-name rule. There’s an open Next.js issue for this same ESLint 10 error: github.com/vercel/next.js/issues/89764 For now I’d pin ESLint back to v9 instead of using ESLint 10: pnpm add -D eslint@^9 eslint-config-next@latest pnpm lint If it still keeps ESLint 10 because of the lockfile, do a clean install: rm -rf node_modules pnpm-lo

Ryu Hi shh, The important clue is that the build output is created under: /vercel/path0/web/.next but the final error is looking for: /vercel/path0/.next/routes-manifest-deterministic.json So I’d treat this as a post-build/finalization path issue before changing the app code. If next build and static generation already complete successfully, the app build itself is probably not the failing layer. A good isolation test is to bypass Git Integration once and deploy a prebuilt output from the app root: cd web vercel pull --yes --environment=production vercel build --prod vercel deploy --prebuilt --arc

Craiguito I’d isolate the database package before blaming Vercel or the whole template. From a clean folder, try the init with pinned tooling instead of all latest versions: corepack enable corepack prepare pnpm@9.15.4 --activate npx next-forge@latest init If it still creates the repo but fails at @repo/database, cd into the generated project and run: pnpm --filter @repo/database build That should give you the real TypeScript/ORM error instead of Turbo’s wrapper error. The log in the post only says the package build failed, not why. My guess is a version mismatch between the template’s database package

Ryu Hi Segal, The log you posted is still Turbo’s wrapper error, not the actual database package error. I’d isolate @repo/database first before treating the whole template as broken. From a clean terminal, try pinning the toolchain instead of using whatever “latest” resolves to: node -v corepack enable corepack prepare pnpm@9.15.4 --activate pnpm -v npx next-forge@latest init If the init still fails but leaves a partial repo behind, go into that repo and run the failing package directly: pnpm --filter @repo/database build or: cd packages/database pnpm build That should show the real TypeScript / O

Ryu Hi Kemal, I’d be careful about concluding this is definitely Vercel blocking dataaccessd just from the app logs. If the request fails at TLS, redirect validation, HEAD handling, or a firewall layer before the function runs, you may also see no application log entry. For iOS Calendar, I’d test the feed like an automated calendar client instead of only from a browser: URL="gocutit.com/api/sync/calendar/example.ics" curl -i -L "$URL" curl -I -L "$URL" curl -i -L \ -A "dataaccessd/1.0" \ -H "Accept: text/calendar,*/*" \ "$URL" I’d want all of those to return a plain 200, not a challenge page, logi