Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

custom integration: injected catch-all route overwrites local routes #6221

Closed
1 task
nowaythatworked opened this issue Feb 11, 2023 · 8 comments
Closed
1 task
Labels
- P3: minor bug An edge case that only affects very specific usage (priority)

Comments

@nowaythatworked
Copy link

What version of astro are you using?

2.0.10

Are you using an SSR adapter? If so, which one?

Vercel (error on dev)

What package manager are you using?

yarn

What operating system are you using?

mac

Describe the Bug

I´m injecting a "catch-all" route [...slug] inside a custom integration. When doing this all other routes I create inside my pages folder can not be found.
I guess something is wrong in the prioritisation.

I´m willing to help fix this if someone can point me to the right direction in code.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/withastro-astro-g758sr?file=astro.config.ts

Participation

  • I am willing to submit a pull request for this issue.
@Princesseuh
Copy link
Member

Closing as a duplicate of #3602

@nowaythatworked
Copy link
Author

@Princesseuh are you sure this is a duplicate?
The entrypoint is not pointing to files inside src/pages in fact it's in its own package. Also this is not about not catching two of the same routes but wrong priorisation.

Usually, inside src/pages you can create a file called '[...args].Astro' and the same directory 'index.Astro'. the index will be served when requesting '/' and this is correct. But as soon as an integration registers the pattern '[...args]' this system breaks. Index is no longer served.

@Princesseuh
Copy link
Member

Ah yes, sorry! I misread the issue, re-opening!

@Princesseuh Princesseuh reopened this Mar 23, 2023
@Princesseuh Princesseuh added the - P3: minor bug An edge case that only affects very specific usage (priority) label Mar 23, 2023
@nowaythatworked
Copy link
Author

Hi @Princesseuh, since this is quite important to me I would love to help fixing this. Could you or somebody else in the team point me towards where the logic for this sits in the code? I´d be happy to create a PR :)

@Princesseuh
Copy link
Member

I believe @bluwy has the necessary context to help with this, though you might have to wait until the work week start for an answer from him.

@bluwy
Copy link
Member

bluwy commented Jun 25, 2023

It looks like injected route taking the highest priority is an intentional decision:

// the routes array was already sorted by priority,
// pushing to the front of the list ensure that injected routes
// are given priority over all user-provided routes
routes.unshift({
type,
route,
pattern,
segments,
params,
component,
generate,
pathname: pathname || void 0,
prerender: prerenderInjected ?? prerender,
});

The PR that added it is #4087. I think what we need is a middleground where injected routes are sorted together with user routes, but injected routes take higher priority than user routes when they have equal priority, e.g. [...injected].astro vs [...user].astro.

I'm not sure how that can be achieved. Looks like it'll take some leg work to combine both sorted routes, but if you're interested in taking a look, the linked code above (injected routes sorting) and this user routes sorting code would be the place to start tweaking.

@nowaythatworked
Copy link
Author

Thanks a lot! I'll definitely check it out and see what I can come up with. The middle ground as you mentioned sounds good to me.

@ematipico
Copy link
Member

This should be fixed now. Closing. If you still have the issue, please create a new issue with a more recent version of Astro

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- P3: minor bug An edge case that only affects very specific usage (priority)
Projects
None yet
Development

No branches or pull requests

4 participants