next.js

91d378db - [test] Capture the route table for apps with several param shapes (#97728)

[test] Capture the route table for apps with several param shapes (#97728) The existing fixtures take a single root param, so they do not cover the shapes that the fallback shell entries can take. This adds fixtures and suites for three more shapes, and pins the entries that each one produces. The first has a root layout that takes two root params, and returns three combinations of them rather than the full product of four. An entry that held each root param position separately would also match `sparse/de`, a combination the build never prerendered, and a request for it would resolve to an output that does not exist. One combination is `acme.one-two,three`, which carries the characters a regex treats as special, and the snapshot shows the build escaping them. The second builds that same app with a single combination, so each source page has one fallback shell. The third has no root params at all. Its root layout sits above the dynamic segments, so `team` and `locale` are ordinary dynamic params that `generateStaticParams` enumerates on a nested layout. The build then produces two shapes of entry for one source page: entries that resolve both params, such as `/sparse/en/posts/[id]`, and entries that resolve only the first, such as `/sparse/[locale]/posts/[id]`. The order of those entries carries the behavior, because a request for `/sparse/en/posts/1` has to reach the output that resolves both params rather than the one that resolves only the first. The snapshot pins that order. Two comments on the Cache Components suite were wrong, and this corrects them. That fixture takes one root param with two values, and not two root params. Its entries also no longer come in pairs, because one entry serves the request for the page, the request for its `.rsc` payload, and a per-segment prefetch.