Open ItsWendell opened 1 month ago
In my previous issue I pasted a wrong reproducable link: https://github.com/vercel/next.js/issues/71086
š
Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote š on the issue description or subscribe to the issue for updates. Thanks!
I've also been wrestling with this issue today. I have an example of a simple project that exhibits this behaviour here: https://github.com/alexfoxy/nextgram-main
To reproduce run the repository and navigate to http://localhost:3000/users/1
.
yarn dev-turbo
)Correctly renderers the user page beneath the user modal
yarn dev
)Renders the wrong page beneath the user modal
Link to the code that reproduces this issue
https://github.com/ItsWendell/nextjs-14.2.15-catch-all-parallel-routes-dynamic-segments-build-issues-repo
To Reproduce
Reproduction:
Clone this repository
ENOENT: no such file or directory, open '/Projects/parallel-routes-catch-all/.next/server/app/(blog)/blog/[slug]/@info/info/[infoId]/page_client-reference-manifest.js'
ENOENT: no such file or directory, open '/Projects/parallel-routes-catch-all/.next/server/app/(blog)/blog/[slug]/@info/info/[infoId]/page_client-reference-manifest.js'
Current vs. Expected behavior
I expect
next build
to compile a valid version, since it works sucessfully in next dev --turbo as I expected. So that I can use the parallel routes together with catch-all routes, as next dev --turbo shows, it should have higher priority than the catch-all route.Provide environment information
Which area(s) are affected? (Select all that apply)
Module Resolution, Parallel & Intercepting Routes
Which stage(s) are affected? (Select all that apply)
next dev (local), next build (local), next start (local)
Additional context
I tested against latest canary
[15.0.0-canary.182](https://www.npmjs.com/package/next/v/15.0.0-canary.182)
too, and the latest stable14.2.15
.Workaround
I found a work around: Instead of using an required catch-all route I've replaced the catch-all route with a non-optional catch all route
[[...slug]]
vs[...slug]
, this seems to continue the build. Not optimal because in some cases you want to have e.g. a seperate page.tsx and a catch-all for all other pages, but we can work around that. This issue is still relevant, since this behavior should be the same with an optional catch all route.