chore: add JSON schemas for the manifests generated by Vite

[nhedger]

Description

This PR adds JSON schemas for the JSON manifests (manifest.json and manifest-ssr.json) generated by Vite.

• manifest.schema.json
• manifest-ssr.schema.json

Both schemas use the 2020-12 draft of the JSON schema specification.

Additional context

Testing the schemas

pnpm run test-build backend-integration

Todo

• Allow additional chunk properties (for plugins)

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[ElMassimo]

Looks great, thanks for making this proposal! 😃

It should make it a lot easier for plugin authors, as well as make it easier to ensure the ecosystem can follow changes to the format in the future 💯

[nhedger]

Thanks for your suggestions !

[nhedger]

Ideally, it should be possible to retrieve the JSON schemas at this URL.

I've versioned the URL to allow for future schemas under a similar URL but I am unsure about how we want to version the schemas.

Mirroring Vite versions

This would probably add some maintenance burden if not automated. Not sure this is a good option because the schema would not necessarily change with each new Vite version.

Sync only the major version

This option would consist in keeping only the major version in sync with Vite, and minor and path version would be incremented when actual modifications are made to the schemas.

For example, schema v2.0.0 would currently be valid for Vite v2.9.6 generated manifests.

Choose later

We don't actually have to choose the versioning strategy right now.

Let's hear pros and cons or other ideas.

[nhedger]

See https://github.com/vitejs/vite/pull/7960/files#r862388528

[nhedger]

Broke my wrist so I'll get back to this in a few weeks.

[patak-dev]

Broke my wrist so I'll get back to this in a few weeks.

Oh, no rush... Take care! I hope you get better soon

[nhedger]

I've rebased this PR to make it work with the upcoming 3.0.0 version. Is is too late to change the manifest and ssr-manifest plugins and add an additional version field to them ? I was thinking about something along the lines of:

- export type Manifest = Record<string, ManifestChunk>
+ export interface Manifest {
+   version: string,
+   chunks: Record<string, ManifestChunk>,
+ }

and

+ export interface SSRManifest {
+   version: string,
+   chunks: Record<string, string[]>,
+ }

[patak-dev]

I added the PR to be discussed in a future team meeting. Vite 3 could give us an opportunity to do this change. I agree that it could be better. Not only for versions, but we may want to include other information in the future.

[patak-dev]

@nhedger we discussed with the team and we would like to avoid changing the schema to add a version at this point. So we could document the current format (taking into account #6649, in case that needs to be also reflected)

[netlify]

✅ Deploy Preview for vite-docs-main canceled.

Name	Link
🔨 Latest commit	4b5fdad
🔍 Latest deploy log	https://app.netlify.com/sites/vite-docs-main/deploys/62bc702e4fd4890008a57727

[nhedger]

@patak-dev I believe #6649 does not introduces any changes to the schema. I've removed the versions from the $id strings of both schemas.

Edit: failing tests do not appear to be linked to this PR.

[bluwy]

@nhedger Since this won't be published to npm, and not served under https://vitejs.dev yet, do you have plans on how the new JSON schemas are used? You mentioned that ideally we'd serve under https://vitejs.dev/schemas/v2.0.0/schema.json for example, is this still needed?

The spec shows that $id doesn't need to be a downloadable URI, so the state of the PR as is should be good too. But with that I'm curious how this file would be used in practice?

[patak-dev]

We aren't currently publishing docs for each patch (we should though), so if we add the version in the URL, it should only use the minor.

[nhedger]

@nhedger Since this won't be published to npm, and not served under https://vitejs.dev yet, do you have plans on how the new JSON schemas are used? You mentioned that ideally we'd serve under https://vitejs.dev/schemas/v2.0.0/schema.json for example, is this still needed?

The spec shows that $id doesn't need to be a downloadable URI, so the state of the PR as is should be good too. But with that I'm curious how this file would be used in practice?

Good point, I actually forgot about that.

Currently, the only way of accessing the schema would be through GitHub (once merged into main):

https://raw.githubusercontent.com/vitejs/vite/main/packages/vite/src/node/schemas/manifest.json
https://raw.githubusercontent.com/vitejs/vite/main/packages/vite/src/node/schemas/ssr-manifest.json

Assuming that everyone agrees, I may be able to setup a GitHub Action to automate copying the schemas to /docs/public/schemas. This could be triggered everytime a new version of Vite is tagged. The schemas would then be served under the URL specified in the $id field.

[bluwy]

If we automate serving them through the public folder, we'd only be able to serve the latest JSON schema at a point of time. So if an old schema points to the URL, and returns a new different schema, would that be a problem?

We could probably solve it by putting the version in the URL, and do a 301 redirect and rewrite the URLs to githubusercontent. But with all these said, I'm be curious to know if the team is fine with this.