fix: Opting out from ISR not working for routes with rest parameters

[hrabiel]

Changes

The logic for generating a match pattern (getMatchPattern) was initially copied from the core astro repository. Since then, the implementation in Astro Core was changed a couple of times. Here is the current implementation of this function in Astro Core: https://github.com/withastro/astro/blob/cd54210/packages/astro/src/core/routing/manifest/pattern.ts#L3.

Looking into .vercel/output/config.json, it was found that the route generated for the excluded path contains an extra slash. Here is an example for a "/excluded/[...rest]" route:

...
{
	"src": "^/excluded/(?:\\/(.*?))?$",
	"dest": "_render"
},
...

However, it should look like this:

...
{
	"src": "^/excluded(?:\\/(.*?))?$",
	"dest": "_render"
},
...

• Changed getMatchPattern() so that it doesn't put a redundant slash before a route segment with rest/spread parameters.
• Changed getMatchPattern() so that it also works for route segments that includes the rest parameter not in the beginning of the segment (e.g. /one/two[...three]).

Testing

Was tested by:

• Adding a modified version of the @astro/vercel package to the example project.
• Deploying it to Vercel and making sure that all excluded routes are not cached.
• Checking a .vercel/output/config.json an making sure that the route with the rest parameter is added with the "_render" dest and the "src" regex is no longer contains an extra prepending slash.

Docs

No need to change the docs because it already mentions this case:

[changeset-bot]

🦋 Changeset detected

Latest commit: 939cbe7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 22 packages

Name	Type
@astrojs/vercel	Patch
@test/astro-vercel-basic	Patch
@test/astro-vercel-function-per-route	Patch
@test/astro-vercel-image	Patch
@test/vercel-isr	Patch
@test/vercel-max-duration	Patch
@test/vercel-edge-middleware-with-edge-file	Patch
@test/vercel-edge-middleware-without-edge-file	Patch
@test/astro-vercel-no-output	Patch
@test/astro-vercel-prerendered-error-pages	Patch
@test/astro-vercel-redirects-serverless	Patch
@test/astro-vercel-redirects	Patch
@test/vercel-server-islands	Patch
@test/astro-vercel-serverless-prerender	Patch
@test/astro-vercel-serverless-with-dynamic-routes	Patch
@test/astro-vercel-static-assets	Patch
@test/astro-vercel-static	Patch
@test/vercel-streaming	Patch
@test/astro-vercel-with-speed-insights-enabled-output-as-server	Patch
@test/astro-vercel-with-speed-insights-enabled-output-as-static	Patch
@test/astro-vercel-with-web-analytics-enabled-output-as-static	Patch
vercel-hosted-astro-project	Patch

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

[bholmesdev]

I noticed this check differs from the core implementation. I believe you said this address the case where a spread param lacks a leading slash (e.g. /path[...spread]). Is there a reason Vercel needs special handling?

[hrabiel]

@bholmesdev great question!
Not exactly. This a replacement for join('/') defined here:

adapters/packages/vercel/src/lib/redirects.ts

Line 66 in 2246e6e

.join('/');

Combined with the check segment.length === 1 && segment[0].spread above, it means "join all route segments with '/', but omit it if the segment is a spread" (e.g. "/path/[...spread]").

And the case you are describing is handled here (I should probably cover it with tests as well):

adapters/packages/vercel/src/lib/redirects.ts

Line 56 in 2625aa3

? '(.*?)'

Initially I copied the core implementation of getPattern() method and tried to use that, but I realized that it would require more code changes around redirects. I've tried to achieve the goal without changing the interface of getMatchPattern() function. If you think that the correct way is to copy getPattern() from core and adjust the rest of the Vercel adapter code accordingly, let me know!

[bholmesdev]

Got it. I can see why we took this route to avoid a larger refactor. I think that's the right move for this PR! I'd consider exposing a utility for this from astro core to consolidate code in the future.