Fix(create-pages): Fix path matching precedence for api routes with wildcard routes

[hamlim]

This change sorts the path configs returned from the getConfig method passed to unstable_defineRouter within createPages, specifically sorting wildcard routes to the end of the list of path configs.

Additionally this PR adds a previously failing e2e test for #1448, which now passes after the change.

Fixes: #1448

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
waku	✅ Ready (Inspect)	Visit Preview	Jun 25, 2025 0:34am

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[hamlim]

Figured I'd try to implement a fix also, pushed a change here: 0805f30 to sort wildcard path configs to the end of the array so we match on them last.

Not sure if this is a naive fix (and maybe leads to other issues), but it seems to make the most sense in that we should probably match explicit path specs first before falling back on wildcard route segments.

cc @tylersayshi

[dai-shi]

Not sure if this is a naive fix (and maybe leads to other issues), but it seems to make the most sense in that we should probably match explicit path specs first before falling back on wildcard route segments.

It might make sense, but I would like to leave this responsibility for create-pages.ts. Can you modify create-pages.ts instead of define-router.ts?

[hamlim]

@dai-shi got some time to take a look at the code again today - I don't think this can be solved for within create-pages.ts as the code is today. There's no exposed hook within defineRouter that allows create-pages to sort the complete list of path specs or to choose the matching path config.

One possible option could be to have defineRouter allow for integrations to pass in a custom getPathConfigItem function (keep the current implementation as a default parameter, maybe tweak it slightly to call getPathConfigItem with the pathConfig and the existing pathname argument), then create-pages could pass in a custom method to sort the list of path configs and then return a .find for the path. Would that change make more sense?

After thinking about my naive solve here a bit more, an even simpler solve could be to move the api route spread here up above the page route spread.

[dai-shi]

Ah I see what you mean. I think we should make some changes in define-router.ts. I can work on it later but not soon.

[dai-shi]

I can work on it later but not soon.

I haven't started. Give me time.

[dai-shi]

I haven't started. Give me time.

👉 #1487

[dai-shi]

@hamlim I'm sorry, but you seem to forget our previous conversation. #1451 (review)

The fix should be in create-pages.ts. Do not modify define-router.ts.

[hamlim]

Sorry about that, updated the branch to apply the fix in create-pages instead!

If defineRouter will be more of a stable public API in the long run - we may want to consider documenting this quirk to let folks know that this issue may happen if they're not using the create-pages setup - but that can be done in a future change

[dai-shi]

Record of flaky tests:

https://github.com/wakujs/waku/actions/runs/15853235995/job/44691999735?pr=1451

Error: 1) [chromium-prd] › e2e/ssg-performance.spec.ts:17:3 › high volume static site generation › build and verify
Test timeout of 60000ms exceeded.

https://github.com/wakujs/waku/actions/runs/15853235995/job/44691999777?pr=1451

Error: 1) [chromium-prd] › e2e\ssg-performance.spec.ts:17:3 › high volume static site generation › build and verify
Test timeout of 60000ms exceeded.

[dai-shi]

LGTM

@tylersayshi Can you have another review?

[tylersayshi]

rest looks good 👍

[dai-shi]

LGTM

[hamlim]

Thanks for all the reviews and feedback!