refactor: routes as virtual module

[ematipico]

Changes

This PR adds a new virtual module that allows to return the list of routes inside an Astro project.

This virtual module essentially replaces the RoutesList type that we create when we start the dev server.

Testing

Unit tests should pass. Integration tests pass on my machine, they will still time out here

Docs

N/A

[changeset-bot]

⚠️ No Changeset found

Latest commit: bdc8f13

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ascorbic]

Will App be able to load this if there are no routes in the manifest?

[ematipico]

Will App be able to load this if there are no routes in the manifest?

Not yet, but now that manifest and routesList are both virtual modules, now manifest can import routesList and update its routes field.

Eventually, App just needs to pull the manifest, and the routes will be there already

[ematipico]

Important

I removed the astro:scanner plugin, and moved its logic inside the new astro:routes plugin. Both plugins need to work around the routes that are created from createRoutesList, and leaving them as two separate plugins was a problem. Merging them made things easier.

[ematipico]

This PR broke a bunch of stuff around prerendering. Currently checking what's the best course of action once I understand the problem clearly

[ematipico]

The problem is caused now by an inconsistency between the dev/ssr pipeline and the build pipeline.

Particularly, there's a plugin called plugin-manifest, which is a plugin excessively used during the build.

I will address this in a separate PR.