Update to astro v5

[san4d]

Summary

• Updates Astro to v5
• Removes deprecated APIs (adapters and @astrojs/webapi). The polyfill is replaced with Astro core's applyPolyfills method, which is used in the Node Adapter.
• Removes the edge deployment strategy
• Removes the serverRoutes from the adapter configuration
• Proposes updating the plugin version to a new major version in beta (3.0.0-beta). This happens to match the SST major version and reflects breaking changes to the API. The beta status reflects the absence of wide testing.
• Related to Updates for astro-sst after SST v3 and Astro v5 sst#5185

Related Breaking Changes

• Deprecated: functionPerRoute
• Properties on supportedAstroFeatures
• Removed: hybrid rendering mode

Out of Scope

• Handling the deprecated builtResult.routes parameter

Outstanding Issues

• Images services are not currently supported on static builds. Investigation required.

[san4d]

@fwang I'm pretty sure this line is why my build fails due to lack of sharp support. I kept sharpImageService: "unsupported" in this MR for parity, but I'm confused: I'm able to deploy on Astro v4 with the current astro plugin. Changing this the value to stable fails for a different reason, which makes sense if there actually isn't support.

Do you mind providing some context into sharp support on static sites?

[fwang]

Does the Astro build output already have sharp bundled in node modules? I vaguely remember it is.
(/cc @nerdoza)

In the context of Lambda, sharp is normally bundled like this https://sst.dev/docs/examples/#sharp-in-lambda

[san4d]

Their docs make it seem like it is:
https://docs.astro.build/en/guides/images/#default-image-service

I use pnpm, so I also have sharp added as a dependency. That said, I'm still observing the issue with the passthrough image service. I'll do more testing here to confirm.

As the library owner, would you expect that sharp would be supported with statics sites? It seems like it was, since I was using it, but the configuration in the current adapter code makes it seem like it wasn't/shouldn't. I'm also not deep with Astro adapters, so it's also possible I'm missing something.

[mvanleest]

@san4d : in the "src/entrypoint.ts" there is also a deprecated import
import { polyfill } from "@astrojs/webapi";

Going to test a bit today... Will comment whatever I find.

[san4d]

Thanks, Michael. Not sure how I missed that in the build. I replaced it with a call from astro core, which I'll add to this MR's description.

[san4d]

@fwang This is another change I wanted to highlight. Without this, I believe the buildOutput would default to server. I'm not sure if that's a bug or expected behavior. As a consumer of the API, I'd expect the output to be static if that's what I passed in.

[fwang]

I think we can also:

• Drop serverRoutes from adapter config. I got a basic version of dynamic origin routing using CloudFront function. This is no longer required.
• Remove edge option from deploymentStrategy. SST can deploy the same build output to a single or multiple regions. So we don't need to maintain 2 different adapters (regional vs edge).