Add build.assetsPrefix option for CDN support

[bluwy]

Changes

RFC: withastro/roadmap#545

The changes are honestly base -> assetsPrefix || base everywhere for asset links. And judiciously handle / where base needs to be prepended by /, and assetsPrefix doesn't.

Testing

Added tests for links, images (experimental and @astrojs/image), content collections, and SSR.

Manual live testing: https://github.com/bluwy/astro-cdn-test and https://bluwy.github.io/astro-cdn-test/

Docs

Document import.meta.env.ASSETS_PREFIX at withastro/docs#2971.

Documentation for build.assetsPrefix is in this PR's @astro/types.ts

[changeset-bot]

🦋 Changeset detected

Latest commit: 168e353

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

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

[sarah11918]

Looking good! Left some tiny edits for consideration! 🙌

[matthewp]

Looks like our minor GH action isn't work.

[yanthomasdev]

Docs LGTM!

[bluwy]

[DOCS] I've pushed another commit to explain the process of serving assets through a third-party domain as suggested by @delucis (7af5d2a)

[ematipico]

I think this looks good to me. What's the expectation of the value from the point of view of the user? It's marked as a string, but if the user puts "anything_fancy", what's the outcome of the build? Should we do some validation? Should we warn the user?

[bluwy]

It would act as a normal prefix so it could be anything. I'm mostly testing values like https://cdn.example.com for now, but it's intentionally lax to allow values like /some/other/root if their deployment setup relies on it.

[ematipico]

Perfect! Thank you for clarifying!

[matthewp]

@bluwy I think in config.ts we specify site to be a URL (it gets refined with new URL()` so maybe it makes sense to do the same here, so that any non-URLs would throw?

[bluwy]

The idea is that it doesn't necessarily need to be a URL, it can be any string prefix depending on their deployment, so I'm not sure if we need that restriction, unless we want to only support URL for now?

[matthewp]

Ah, no, good point. It could just be a path. In that case I agree, let's leave it as a string for now.

[gkatsanos]

It would act as a normal prefix so it could be anything. I'm mostly testing values like https://cdn.example.com for now, but it's intentionally lax to allow values like /some/other/root if their deployment setup relies on it.

I think I found an issue with this second type of values: #6844