add dev checks for plugin route conflicts

[deer]

We should add two checks here:

1. routes within a plugin conflicting are conflicting with each other. The plugin author has done something really silly! (Maybe this isn't even necessary?)
2. routes across plugins conflicting with each other, or with the user's routes. This is very possible to happen.

from: #1545 (comment)
@mbhrznr, any interest in picking this up? 🤞

[mbhrznr]

count me in! 💪

[thegaryroberts]

On point 1: When starting out I got caught out a lot with routes conflicts when having dynamic routes at the same directory level as named routes... plugin authors might make the same mistake. Also it would be good to validate this for routes in general (if this doesn't happen already).

Or at minimum the docs here could do with a note about this gotcha: https://fresh.deno.dev/docs/concepts/routing

[mbhrznr]

was finally able to pick this up:
given that allRoutes in our context already contains the manifest's routes as well that all of the plugin routes, we already should have some base coverage on the conflicts w/ #1568.

however as mentioned by @thegaryroberts i'd invest some time in checking dynamic route conflicts.
currently we'd only have checks for strict equally on the patterns, yet something like /products/:id and /products/:article wouldn't be picked up.

[mbhrznr]

as expected the checks were also applicable for plugins ootb.
added a dedicated check for dynamic routes to #1568.

[mbhrznr]

was scanning the still open prs, wouldn't this be tackled by #1414 anyway?
@deer if you want to i can migrate that into #1568 as well, seems to be way more robust than my current approach.

[deer]

I must admit I haven't checked whether what I've done for 1414 covers routes added by plugins. But as I'm reading it over, I guess the approach would work, since it checks after routes have been loaded. How do you want to proceed?

[mbhrznr]

if you don't mind, i'd migrate #1414's changes into #1568 to bundle all of the dev checks under one umbrella pr.
however we might want to add some further meta information about the type of routes, as routes from plugins get the ./routes* prefix via getRoutesFromPlugins.

thus the warning would always contain ./routes/<pattern> even though the warning originated from a plugin route.

---

for now i'd also set #1568 back to a draft state.

[deer]

Ok, so I'll close #1414 and you can update #1568 so that it closes this issue and #475. Sound good?

[mbhrznr]

sounds like a plan! thank you!

[deer]

And don't forget to get 539 closed as well!