refactor(next): send IntegrationRouteData to integrations

[ematipico]

Changes

Closes PLT-2338

This PR changes the type passed to integrations regarding the routes. RouteData was never meant for external usage, in fact it lacks JSDocs.

This wasn't intentional, and with v5 we plan to fix this. In fact, with the new type IntegrationRouteData, we removed isIndex and fallbackRoutes from being passed to the integrations, because they were never meant to be used by downstream integrations.

With this PR, I took the chance to add some proper documentation, so downstream developers (and us), know what each field is about.

Also, this PR fixes a critical bug. RouteData.distURL needs to be an array, because a route can generate multiple files, and until now we were saving only the last file generated.

This PR changes to be an array, which is marked as a breaking change.

Testing

The existing CI should pass

Docs

Added changesets

withastro/docs#9273

[changeset-bot]

🦋 Changeset detected

Latest commit: eea2150

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

[github-actions]

This PR is blocked because it contains a major changeset. A reviewer will merge this at the next release if approved.

[alexanderniebuhr]

We have moved the adapter to https://github.com/withastro/adapters, so this PR can't be merged here anymore.
I would offer to port over the changes to the new repo for you, just let me know if you want me to do that.

[Fryuni]

It might be worth documenting what value will be here in case of redirect and fallback routes since this is not optional and yet those types don't necessarily have a component.

[florian-lefebvre]

@Fryuni what would you propose then?

[Fryuni]

Since this is for next major I think it would be better to change the name of this field to something like subject and then document what it means for different route types.

• For page routes, it is the Astro component to be rendered.
• For endpoint routes, it is the file declaring the method handlers.
• For redirect routes, it is the target mask of the redirect.
• For fallback routes, it is the subject of the route used as fallback.

[alexanderniebuhr]

I ported over the adapter related changes here withastro/adapters#377

Changes ported to the adapters repo

[florian-lefebvre]

We discussed with the rest of team platform and sounds like we want a bigger refactor of this interface, not just a proxy of the internal type

[matthewp]

@florian-lefebvre I don't think we said we shouldn't merge this though. Unless we have a solid idea for such a refactor this is a small improvement.

[florian-lefebvre]

ah that's not what i understood! Feel free to merge as is then

[bluwy]

To clarify a bit, in the last standup I brought up that I hoped the API would shrink down by a lot more (like 3-5 properties only). Designing it as if from scratch, exposing the crucial ones, rather than exposing as much as possible to keep backwards compat for integrations who use them. Because I think routes in its entirety wasn't meant to support those usecases in that way in the first place.

But anyways I don't mind this merging and we can re-iterate again in the beta if we want.

[Fryuni]

IIRC Ema did this on a TBD and most of the fields were being used by official UI framework integrations and adapters. So this just separates the types so they can evolve independently and we can then see whether the features relying on those fields should be implemented differently.

Fine for now

[ematipico]

Yeah, I can confirm that all fields exposed by the new interface are used by integrations and adapters maintained by us.

I believe that's one of those cases where we would like to refactor it, but it's too late now