refactor: support devtoolbar

[ematipico]

Changes

This PR enables the devtoolbvar inside the DevApp by passing the devtoolbar information via manifest.

I added new types inside SSRManifest. This information is pulled using settings.preferences and getInfoOutput, which are serialisable and can be passed via vite plugin.

These new types are placeholders when building and serialising the manifest for SSR during the build

Testing

Manual testing. I could see the devtool popping up and working. The debug info are also available and visible

Docs

N/A

[changeset-bot]

⚠️ No Changeset found

Latest commit: 428de2c

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]

The failing tests are presumably outdated, as they use the old manifest stuff

[florian-lefebvre]

Is the ssr manifest really the right place to store this data? I mean since it's only used in dev. Could it be possible to make the dev pipeline accept toolbar info as another argument?

[ascorbic]

@florian-lefebvre with the env API, everything needs to be in the manifest

[ematipico]

Is the ssr manifest really the right place to store this data? I mean since it's only used in dev. Could it be possible to make the dev pipeline accept toolbar info as another argument?

That was my initial implementation, and it's not the right call (personal opinion). The dev toolbar is connected to AstroPreferences, which are very tight to Node.js (it does FS operations). To work around that, it means we would need yet another virtual module just to pass that information.

However, I didn't want to pass "yet another parameter" to the DevApp module because I think AstroPreferences are an implementation detail of the application, and a power user shouldn't bother passing them. Also, since this information rarely changes, I thought we could pass it to the manifest.

It's true that this information is for dev only, however it felt like a massive refactor just for accommodating AstroPreferences

Let me know what you think

[florian-lefebvre]

Okay no problem! I'd like to look into this later next year, would you mind adding a todo comment somewhere?