-
Notifications
You must be signed in to change notification settings - Fork 514
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
fix: apply cached rules to overlaping wildcard patterns #906
Conversation
Codecov Report
@@ Coverage Diff @@
## main #906 +/- ##
==========================================
+ Coverage 67.48% 67.76% +0.27%
==========================================
Files 59 59
Lines 5911 5968 +57
Branches 660 677 +17
==========================================
+ Hits 3989 4044 +55
- Misses 1913 1915 +2
Partials 9 9
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
This is a smart solution! I agree. I think would be better that we move this to handler generation in build time and reduce runtime overhead. Route rules should be pre-determined in build time if we expect them universally so should be fine... |
Updated. β One comment - it's occurred to me that we also need to track nested conditions, for example: /posts/test: { cache: false }
/posts/**: { cache: true }
/**: { cache: false } My last commit should hopefully handle this as well. |
π Linked issue
resolves #905
nuxt/nuxt#18745
β Type of change
π Description
If a cached route rule is created for a path that would match but is not equal to a glob pattern, we do not currently cache it (because the entire handler can't be cached).
We can work around this by adding a duplicate handler that we will cache, that matches the more specific variant.
An example is where we have a glob
/**
handler but only wish to cache the path/foo
or/foo/**
. In this case we need to add new handlers to cover these more specific prefixes.Note: I've added this in the runtime code because that's where the existing processing of route rules happens. It would of course be possible to move all of this code straightforwardly to https://github.com/unjs/nitro/blob/6541373545ee2716566bce46c7568ad2c3164cdf/src/rollup/plugins/handlers.ts#L20-L26, but that is also true of these lines of code and I think we must have a good reason to keep them there (such as potentially setting route rules at runtime).
π Checklist