Reintroduce flat routing
PR Checklist
Please check if your PR fulfills the following requirements:
- [x] Tests for the changes have been added (for bug fixes / features)
PR Type
What kind of change does this PR introduce?
- [ ] Bugfix
- [x] Feature
- [ ] Code style update (formatting, local variables)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] CI related changes
- [ ] Documentation content changes
- [ ] infrastructure changes
- [ ] Other... Please describe:
What is the current behavior?
Changes to nested route escaping in RC0 broke what was essentially flat routing, where files/folders named along the lines of a.b.c would have their path become a/b/c. This is useful for reducing folder nested. Whether it was an intentional behaviour previously I'm not sure, but I'd like it to be there.
What is the new behavior?
Adds back the . -> / regex that was removed in RC0, bringing back flat route support.
Other information
Having flat routing alongside nested routing does add the potential for multiple definitions of the same route, but IMO the convenience outweighs that risk
🦋 Changeset detected
Latest commit: 59094aafb20d31686af9d001fc92d240edbecf37
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
One thing I wasn't sure about here was what this did for people who wanted . in the path. I added it to solve unnesting very briefly and almost immediately regretted it. That's why I went back against this because I could already picture the issues being opened when someone made route.json.ts and it wasn't at route.json. There are cases where people make extension specific routes at minimum. Especially for known things like... manifest.json etc. I know Remix does flat routing. Did they ever solve this?
Looks like Remix use [] to escape characters, whether that's individual periods with manifest[.]json.ts or entire file names like [manifest.json].ts. They use $ as their dynamic route prefix similar to how SS uses : so there's no conflict with dynamic files, but they also use $.ts on its own (which i quite like tbh) to do splat routes, whereas for us doing something like [...rest].tsx would conflict with our splat routes.