fix(vercel): copy static assets after all integrations

[ascorbic]

Changes

Adapters need to run before all other integrations, which is enforced in builds. This causes a problem for the Vercel adapter, which copies static assets from the dist folder into the .vercel/static folder after the build in the 'astro:build:done' hook. For integrations that also generate assets in 'astro:build:done' (such as sitemap and partytown), this means that they are too late, and generate the assets after the adapter has copied them to the deploy dir.

This PR does a bit of a sneaky trick: it adds a second integration, which isn't an adapter, and so can run after all others. That has its own 'astro:build:done' hook which does the copying.

Fixes #445

Testing

Added fixture and test suite

Docs

[changeset-bot]

🦋 Changeset detected

Latest commit: 83ba9f9

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

This PR includes changesets to release 20 packages

Name	Type
@astrojs/vercel	Patch
@test/astro-vercel-basic	Patch
@test/astro-vercel-image	Patch
@test/astro-vercel-integration-assets	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-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

[florian-lefebvre]

LGTM. Only issue I can see is that another integration could be added after this one from within an integration:

• adapter adds integration X
• integration Y adds integration Z
• X runs (adapter assets copy)
• Z runs

So if Z adds some assets they will not be copied. This should be rare tho. Maybe a way to work around that is for the adapter to inject an integration that injects an integration:

• adapter adds integration X
• integration Y adds integration Z
• X adds integration W
• Z runs
• W runs (adapter assets copy)

This is not bullet proof of course

[ascorbic]

But what if another integration injects an integration that injects an integration? Maybe we should inject an integration that injects an integration that injects an integration that injects an integration

[florian-lefebvre]

Lol I'm not sure if you're joking but I'll assume you don't. I'd say it's quite common for an integration to inject another (eg. to organize code mainly) so handling one level would be enough. But I'm fine with the current fix