It doesn't. Those are executed build-time and you can't just set a wildcard so anything outside the given set results in 404.
As background, I wanted to make a PoC with NextJS bundled into a static CapacitorJS app somewhat recently and had to give up because of this.
You can try tricking NextJS by transforming the pages into "normal" ones with eg query parameters instead of path, but then you need complicated logic changing the pages as well as rewriting links. As you of course want the normal routes in web app. Just a huge PITA.
Not sure why you gave up. All you need to do, is use query params: /todo?id=123 and use `const { id } = useSearchParams()` in your code. Yes, the urls won't be that pretty, but I don't know if this is a road block. I have a NextJS webapp up and running that is 100% SPA (no SSR, full static export) and uses a C#/.NET REST Backend for data [0]. Works (almost) flawlessly.
No. I disagree, you have to refactor all the pages from using [pathId] folder pattern and change all the links including switching to useSearchParams. It's just a huge change, especially if I want to keep the old routes in my web app.
Yes it would, and I can see with an existing app that it is work. But we are probably talking less than a days work? Not even using AI, but this is straightforward string replacements.
Right. So a custom build system which changes the built pages from dynamic path folders to named folders in a day. No bugs. Sure. Also I serve rich-text content with links so those gotta be rewritten as well.
As background, I wanted to make a PoC with NextJS bundled into a static CapacitorJS app somewhat recently and had to give up because of this.
You can try tricking NextJS by transforming the pages into "normal" ones with eg query parameters instead of path, but then you need complicated logic changing the pages as well as rewriting links. As you of course want the normal routes in web app. Just a huge PITA.