Adapters not following the route priority ordering after build #11266
Comments
|
I was hoping, when I saw the changelog, that Astro 4.10.2 would have fixed this, but no such luck. I have updated the version numbers. |
|
Hey, @lschierer! Thanks for the report. This is not a problem on Starlight. It is partly on Astro core and the Node adapter (on every adapter). The problem can be reproduced without Starlight: What is happening is that the routing priority rules used on the dev server and on the build do not match the wiring in the adapter. The adapter presents all pre-rendered content first and looks for dynamic routes only when no pre-rendered content is found, which should be the fourth rule, not the first. I'm gonna transfer this issue to the core repo so we can track it there 😄 You mentioned that the original problem was on an AWS adapter. You'd probably have to open an issue with them to either fix the adapter so it follows the priority rules or document the rules they follow. Astro doesn't have a first-party AWS adapter. |
|
I figured I had even odds of being wrong either way, thanks for transferring the report to the right place. |
Fryuni
changed the title
Fryuni
added
- P3: minor bug
|
Thinking a bit more about this, it falls into a situation that it was supposed to show you a warning about the conflict (it is one of the known false negatives at the moment) and in the future we plan for that to be an error (essentially you can't build a website where a page is entirely discarded). Fixing the page generation within the |
|
oh. I will have to think of something else then because I would be discarding one page in either case, evenif the adapters processed the rules as I expected. I am purposely overloading the route because then starlight includes it in the sidebar nav menu automatically. its a neat trick when the specificity rules are honored by the adapters.
Jun 15, 2024 14:19:44 Luiz Ferraz ***@***.***>:
Thinking a bit more about this, it falls into a situation that it was supposed to show you a warning about the conflict and in the future we plan for that to be an error (essentially you can't build a website where a page is entirely discarded).
Fixing the page generation within the astro package should fix this for all adapters and provide a proper warning that it is happening.
—
Reply to this email directly, view it on GitHub <#11266 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ67LFLZUN3BILLXV3XATDZHSAT7AVCNFSM6AAAAABJLOWKKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZQGQ3DQNJQGM> .
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AAQ67LFRMBETD6BAFNGZY3LZHSAT7A5CNFSM6AAAAABJLOWKKOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUBL24JO.gif> Message ID: ***@***.***>
|
with the start of putting tools in thier own path due to a comment in withastro/astro#11266
What version of
starlightare you using?0.24.1
What version of
astroare you using?4.10.2
What package manager are you using?
pnpm
What operating system are you using?
Mac
What browser are you using?
Chrome
Describe the Bug
I've found what I think is a routing bug that I'm not sure if its becuse of the starlight integration or not. (If not, I'm happy to refile this with Astro itself) I've got a minimal reproduction at https://stackblitz.com/edit/github-lsqplx
if you run this with
npm run devthe two links I put on the home page, "broken" and "works" are identical (they should be). But if you run it as a node site as if deployed withnpm run build && node dist/server/entry.mjsthen they differ, in that the one that is pre-rendered ("works") works and the one marked to be dynamic ("broken") gets intercepted by starlight instead.Ideally both should work the way the one I've labeled "works" does. Minimally they should work the same whether I run
npm astro devornode dist/server/entry.mjsnote that I've first hit this on my actual repository using pnpm on OSX and the AWS adapter whereas the Stackblitz uses npm presumably on Linux with (obviously) the node adapter. So the bug is
Link to Minimal Reproducible Example
https://stackblitz.com/edit/github-lsqplx
Participation
The text was updated successfully, but these errors were encountered: