generateStaticParams() not detected when using parallel routes / dynamic routes using output: export

[KoenLemmen]

Link to the code that reproduces this issue

https://github.com/KoenLemmen/nextgramminimal/

To Reproduce

1. Start application in dev mode (application won't build with the same error)
2. Go to localhost:3000/
3. Click one of the "images"
4. No modal opens
5. Error happens:

Error: Page "/@modal/(.)photos/[id]/page" is missing exported function "generateStaticParams()", which is required with "output: export" config.
    at DevServer.renderToResponseWithComponentsImpl (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\base-server.js:1071:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async DevServer.renderPageComponent (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\base-server.js:1913:24)
    at async DevServer.renderToResponseImpl (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\base-server.js:1951:32)
    at async DevServer.pipeImpl (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\base-server.js:911:25)
    at async NextNodeServer.handleCatchallRenderRequest (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\next-server.js:272:17)
    at async DevServer.handleRequestImpl (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\base-server.js:807:17)
    at async C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\dev\next-dev-server.js:339:20
    at async Span.traceAsyncFn (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\trace\trace.js:154:20)
    at async DevServer.handleRequest (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\dev\next-dev-server.js:336:24)
    at async invokeRender (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\lib\router-server.js:174:21)
    at async handleRequest (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\lib\router-server.js:353:24)
    at async requestHandlerImpl (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\lib\router-server.js:377:13)
    at async Server.requestListener (C:\Users\koenl\Downloads\april\nextgram\node_modules\next\dist\server\lib\start-server.js:141:13) {
  page: '/(.)photos/1'

6. photos/[id] is opened instead of @modal/(.)photos/[id]

As can be seen in @modal/(.)photos/[id] the exported function is present.

Current vs. Expected behavior

Current behavior:

• Modal path errors and non modal path opens
• generateStaticParams() is not detected and used

Expected behavior:

• Modal path is opened
• Modal path uses generateStaticParams()

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
  Available memory (MB): 65463
  Available CPU cores: 24
Binaries:
  Node: 20.8.1
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.0-canary.51 // Latest available version is detected (14.2.0-canary.51).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.3
Next.js Config:
  output: export

Which area(s) are affected? (Select all that apply)

App Router, Data fetching (gS(S)P, getInitialProps), Static HTML Export (output: "export")

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

Additional context

Unsure but might be related to: #52842

_NEXT-3296

[Syhans]

Can confirm, I have the same issue for basically the same use case. For what it's worth:

• I checked several Next 14 releases (14.1.4 (current latest), 14.0.0, 14.0.1, 14.0.3 and 14.1.1, as well as the current canary 14.2.0-canary.61) and get this behaviour with all of them.
• The app behaves as expected when not using output: "export". Which, granted, is not very helpful when the goal is to create a static site.

[NeoPrint3D]

Any Progress or updates? This issue is super dumb especially if vercel wants to ease people into using nextjs from an old codebase or vite.

[KoenLemmen]

Not that I know of. Still broken in 14.2.1-canary.6

[dylan-sharp]

I am experiencing this issue as well and I am using app router

[PArns]

My page heavily uses parallel routing, which ultimately ends in just having dynamic rendering and no SSR at all.

So adding this feature would be really beneficial -> https://patrick-arns.de

[KoenLemmen]

Looks like this issue is wrongfully tagged as pages router. I did say in the post its an app router bug.

[elmarsto]

this should be a hi-pri fix, it makes parallel routes useless for a number of important use cases, e.g. an edit modal that takes an id in the path

[KoenLemmen]

I agree. Modals in general don't work due to this, the minimal I attached is their own example.

[KoenLemmen]

Not yet but I'm hoping #65348 might also fix this.

Edit: checked canary up to [15.0.0-canary.19]. Bug still present.

[KoenLemmen]

Present in 15.0.0-canary.37

[brense]

This bug is present regardless of which output mode is used in next 14.2.5.

If you use a catchAll route [...rest] in one of the parallel routes, you can work a little bit around it by adding the routes you want to generate in the getStaticParams of the root layout (where the parallel routes are used).

[christiankaseburg]

Any updates on resolving this bug? I am experiencing the same build errors related to my parallel intercepting routes with my static application that I build with next.config output: "export".

[KoenLemmen]

Updated the minimal to use next-async-request-api and to the latest canary 15.0.1-canary.0.
Unfortunately the issues are still present.

[eliot-akira]

Still seeing this on 15.0.1. I tried the proposed fix in PR #65348 but it didn't solve it. The error message is confusing because there is export const generateStaticParams in the referenced route.

For me the error goes away if I comment out i18n from the next config. Looking at the docs for i18n, I think my setup is not configured correctly, and the error actually means "route not found".

Possibly related:

• Unexpected behavior when using output: 'export', generateStaticParams(), and export const dynamic #56253
• Error: Page "/docs/[[...slug]]/page" is missing param "/docs/test/" in "generateStaticParams()", which is required with "output: export" config. #56477
• generateStaticParams issue with output: "export" in config during development #64906

[hamonCordova]

Same here. I need static pages with i18n. The error occurs even if I put the generateStaticParams where were suggested.

[Sardor-M]

I can confirm i am getting the same app router bug being thrown in the "next": "^15.0.3", version. Below is the error message in detail:

⨯ Error: Page "/events/upcoming/details/[id]/page" is missing exported function "generateStaticParams()", which is required with "output: export" config.
at DevServer.renderToResponseWithComponentsImpl (node_modules/next/src/server/base-server.ts:1979:16) {
page: '/events/upcoming/details/3'

Any workaround or help is appreciated. Thank you !

[trm217]

This issue is still occuring as of v15.1.4, even when using standard output settings (non export).

[KoenLemmen]

Updated the minimal to use 15.1.5.

Things have changed. There's no longer errors when using the dev server and both navigation to a new tab or modal work.
However, unfortunately this does not work for the build yet, the build has no errors but the behaviour described above is not present in the export build.

What I think should happen:

• If url gets loaded directly the photo just opens (this is working properly)
• If the image gets clicked next should capture the event and instead of directing the user to the page, it should run the modal code (this only happens in dev right now, no parity with the export)

I do think this is a step in the right direction. No more errors, functional when running pnpm dev, feels like we're this close to having modals work with static exports.

[ztanner]

Hi all, thank you for the report!

Parallel routes should work fine with output: export. And indeed, that erroneous build error should no longer be happening in latest versions. However, looking at the reproduction, the problem is specifically with interception routes. Interception routes are built on top of parallel routes, but they make use of rewrites to determine which page component should be rendered during a client navigation.

Rewrites are one of the things that we've documented as not being supported by output: "export" (ref) as they currently require a server to handle. However, it's an oversight on our part that we do not explicitly document interception routes as being unsupported, and that we aren't erroring when we detect interception route usage in an exported app.

We'd like to support as many features as possible with output: export, and have ideas on how to make this work in the future. I'll leave this issue open until we can get proper documentation & feedback in dev that it's not yet supported.

[KoenLemmen]

Thanks for your response and explanation ztanner.
I get how generally rewrites can be a complex topic.
But for the case of modals as with this minimal, I do not understand how the client's javascript can't just open the modal.
When the url is opened directly or opened as a new tab it functions accordingly already as these routes are just generated files for the webserver to serve.
There really only needs to be something in next that recognizes the modal pattern and let the client treat it as such.
Especially since the modal can also be pregenerated or just be a client component, there really is no need for a server in this case.
It's not so much a rewrite as just opening a new component.
No use of headers or redirects. Just open te modal, update url and history, no actual networking actions.
To me it feels like just sending an error and blaming it on the redirect cases that do not fit these properties is not a real fix.

[trm217]

@ztanner thanks for your explanation.
I ran into this issue just yesterday, when attempting to statically render an mdx blog, based on the content of a folder, for which I used getStaticParams.
You say that should habe worked?

[ztanner]

Thanks for your response and explanation ztanner. I get how generally rewrites can be a complex topic. But for the case of modals as with this minimal, I do not understand how the client's javascript can't just open the modal. When the url is opened directly or opened as a new tab it functions accordingly already as these routes are just generated files for the webserver to serve. There really only needs to be something in next that recognizes the modal pattern and let the client treat it as such. Especially since the modal can also be pregenerated or just be a client component, there really is no need for a server in this case. It's not so much a rewrite as just opening a new component. No use of headers or redirects. Just open te modal, update url and history, no actual networking actions. To me it feels like just sending an error and blaming it on the redirect cases that do not fit these properties is not a real fix.

If you aren't interested in the interception behavior of modals, then you can implement the modal with a parallel route. Interception routes are only necessary if the goal is to show a different experience when performing a client navigation (eg soft nav) vs landing directly on the page. The former will show the interception route, the latter will show the underlying page component.

If you don't need that behavior, then you're able to implement the modal pattern with parallel routes and output: export. However, if you need the deeplinking behavior, that's where there's additional complexity that currently requires a server to determine if, based on a particular request, it should serve Component A or Component B.

Here's an example: https://stackblitz.com/edit/nextjs-c5zar9uk?file=app%2Fpage.tsx
And another with a visual example: https://x.com/asidorenko_/status/1725548472839950553?lang=en

@ztanner thanks for your explanation.
I ran into this issue just yesterday, when attempting to statically render an mdx blog, based on the content of a folder, for which I used getStaticParams.
You say that should habe worked?

I can't really determine that from your message: it'd be best to open a new issue with a minimal reproduction if your case isn't working, and you're not using intercepting routes + output: export.

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