In the case of Nuxt (which by default uses basically the same paradigm) I could circumvent this by using the package @nuxtjs/router.
I have no idea why this is the default behaviour, it sure feels something like a lot of people put a lot of work into and by then they didn't realise their fancy new feature doesn't make things better.
I think it’s a part of their convention over configuration philosophy. Say what you will about it, there are obviously drawbacks.
But I’ve noticed that it makes it easier to quickly understand new codebases in my organization. Everyone are using Next.js and all the apps have about the same file layout.
And it makes the routes easily greppable in VSCode/Ag/Telescope/CrtlP which I think is the thing motivating it.
I think it’s neat that having extremely fast project dir fuzzy finders has influenced framework design. Like how Django’s design is heavily influenced by how importlib works and would be completely different if Python modules worked differently.
What is a good argument against it? It makes understanding the layout of the website easily and saves you from having to come up with your own <custom> conventions around it.
I generally prefer keeping all the configuration in as few languages as possible and preferably in a single language. Adding filesystem-based config where a config option object in the main language of javascript would suffice goes against that.
Also, given a filesystem config, now I'm forced to have many very small files around for each route where each file is most likely just a call to another service handler. I'd prefer to mash most into bigger files that handle related but distinct routes.
Less important, but comes up, it's nice to be able to match routes based on code and not just string equality ... e.g. everyone seems to like having routes for usernames start with '@'
I have no idea why this is the default behaviour, it sure feels something like a lot of people put a lot of work into and by then they didn't realise their fancy new feature doesn't make things better.