feat(vercel): allow external redirects

[wotschofsky]

This PR was originally opened on the main Astro repo: https://github.com/withastro/astro/pull/11422

Changes

Before:

Redirects with schema defined in astro.config.mjs were converted into paths on the same site: https://google.com -> /https://google.com

After:

External redirects are detected and don't have the project base path prepended.

Testing

The output (esp. .vercel/output/config.json) of building a project with the updated integration was manually inspected.

A test was added

Docs

The Astro docs generally state that supporting external links configured through astro.config.mjs isn't a goal. While the Cloudflare adapter already supports external redirects, the Vercel adapter handled external redirects differently so far. Therefore this could potentially be considered a breaking change.

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 6c06aba35d4e0653a91fe7c61e679baff8de9da7

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	Minor
@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

[iLynxcat]

Was wanting to set up some external redirects for a site I’m working on, is there anything that would help this gain some traction towards a merge? Would happily help work on this to get support in an upcoming release!

cc @ematipico

[wotschofsky]

I believe this is currently blocked because of the question of whether external redirects should be supported through redirects in config.

Again, here's why I believe they should:

1. Exposing only a single property, which is also understood by all adapters, is the most intuitive option
2. The implementation overhead for differenciating between internal and external redirects is minimal
3. Other adapters (like @astrojs/cloudflare) already support external redirects from redirects, making it again more intuitive and reducing friction when switching adapters

[iLynxcat]

Cheers for the response! It wasn’t quite clear from where the previous discussion ended, thanks for clarifying.

1. Exposing only a single property, which is also understood by all adapters, is the most intuitive option
2. The implementation overhead for differenciating between internal and external redirects is minimal

Agreed, matching with /^(https?:)?\/\//) is the simplest match I can think of.

3. Other adapters (like @astrojs/cloudflare) already support external redirects from redirects, making it again more intuitive and reducing friction when switching adapters

For sure! I don’t think this should ideally be adapter-specific. Would love to hear exactly what Astro maintainers envision here, but I think this is a solid proposal.

Only issue I see with using URL.canParse() is that I’d like to maintain the ability to specify URLs in network-path reference format (//example.com instead of https://example.com) to maintain full compatibility with browser standards. My opinion is that it’s not the framework’s job to tell the developer not to use it, even if it’s rare and probably shouldn’t be used in most cases.

Thanks for hearing out my mini-rant there :)

[florian-lefebvre]

@ematipico will this PR still useful with external redirects officially being supported in core from 5.2?

[ematipico]

Core now supports it, this PR shouldn't be needed

[florian-lefebvre]

Thanks for trying @wotschofsky!