pages patterns overlapping with server routes

[pi0]

Context: @manniL / https://github.com/nuxt/nuxt/issues/25707

If there is a page pattern for rendering /foobar and also server/routes/foobar or (more commonly) a wildcard pattern, we shall warn users that it is happening.

Update: https://github.com/nuxt/nuxt/issues/25709#issuecomment-2345577725 We might alternatively think of a system that matches nuxt router to nitro with Nitro v3 Nuxt v4.

[jamesdawsonWD]

Hey @pi0

I am attempting this as my first issue! I was looking through the codebase for the first time last night and I have some questions.

My plan was as follows

• Find where the pages are being read and stored
• Find where the routes are being read and stored
• Find some sort of "build complete" lifecycle hook
• Get both states into this hook
• Call an algorithm that will check for any overlap in naming between pages and routes
• Log a warning

I managed to find where the pages are stored inside Nuxt.apps context object that is being passed to the hook but I was unable to find any of the server routes. They must be being read somewhere but I couldn't find them inside the Nitro context object that is passed into build(nitro).

I don't want to arbitrarily read all the filenames if I am certain they are happening somewhere in the pipeline. My assumption is the reading is happening inside the nitropackage but I could be 100% incorrect on this!

My questions:

• Where, if anywhere, can I find the server route names?
• Does my plan sound like I am on the right track?
• When you say a wildcard route can trigger the warning do you mean that server/api/[...].ts would cause an overlap with pages/foobar.vue and if that is the case would having this wildcard not overlap with every pages route in the root dir?

[daleweaver777]

What would be awesome is when Nitro matches the route, have some way to abort handling the request and allow Nuxt to handle the request.

Example Route Structure server/routes/[slug].get.ts pages/index.vue

If the the param in [slug].get.ts in Nitro doesn't match a certain criteria, you should be able to defer handling the request to Nuxt and render index.vue instead.

A great use case would be a url shortner app. If the slug param isn't in the redirect database, render the index.vue page instead of a 404.

[Gonzo17]

• Does my plan sound like I am on the right track?

I don't know about that since I'm not familiar with the nuxt core, but I'd like to find that out as well and help if needed! I've come across this in one of my projects and think a warning would really help.

• When you say a wildcard route can trigger the warning do you mean that server/api/[...].ts would cause an overlap with pages/foobar.vue and if that is the case would having this wildcard not overlap with every pages route in the root dir?

Testing around, I realised that server/routes/[...].ts doesn't work, while server/routes/test/[...].ts does. So one example is if you have server/routes/test/[...].ts and something like pages/test/foobar.vue.

I think that server/routes/[...].ts doesn't work is to prevent that someone blocks page rendering by accident, but wouldn't that also be worth a warning?

Thinking about it, there come more questions to my mind:

• Would having something like server/routes/foobar.post.ts still be worth a warning? It would overlap with the path of pages/foobar.vue, but since the method is different, both will be accessible.
• When someone uses a catch-all route for pages like pages/[...].vue, do we still want to have a warning? Effectively it will clash with every middleware route defined. A use case for that is if you have a CMS. The nuxt application doesn't know about the paths, it just sends them to the CMS. In that case you usually just have a couple of Nuxt pages or just this catch-all route. The warning would not be helpful here, so do we want to ignore this case?

What would be awesome is when Nitro matches the route, have some way to abort handling the request and allow Nuxt to handle the request. [...] A great use case would be a url shortner app. If the slug param isn't in the redirect database, render the index.vue page instead of a 404.

I feel like this would make things more complex than necessary. In your use case I would suggest to let the pages handle what is shown and create an endpoint in api rather then routes. If you want to handle redirects before the user enters the page, you can even add a router middleware that calls /api/some-slug and decides if the user should be redirected to home based on the result. I've done that in a chat application where I generated invitation links for chat rooms that are only available as long as someone is still in there.

But I also might be wrong here and my approach was not a best practice. So further thoughts to this topic are appreciated. :)

[pi0]

Thanks for the valuable feedback dear @Gonzo17. The warning should be for GET/HEAD/ALL handler collisions only you are right.

I am thinking more about it and it is probably worth more consideration, especially with Nitro v3 and the new router we have a chance to expose a hook that allows the Nuxt framework to predict renderer route match and actually merge two routers. (it definitely has a cost and i am trying to find a way to minimize it)