`prepare`-style subcommand that frameworks can extend

[KTrain5169]

Description

Various frameworks use some sort of prepare script (or have functionality that suits well for a prepare script):

• Nuxt and Astro generate .nuxt/.astro folders containing TypeScript definitions. As "super meta-frameworks" with their own CLIs that wrap everything Vite, they choose to have their own prepare subcommands in their CLIs (nuxt prepare/astro prepare) for this behaviour, and encourage projects to run this command after npm install (based on their scaffolding CLIs).
• SvelteKit also has their own CLI, even as a "framework-as-a-plugin" type of framework. They also ship their own svelte-kit CLI with svelte-kit sync -> same idea as astro prepare/nuxt prepare. More info by a SvelteKit maintainer here: prepare-style subcommand that frameworks can extend #23367 (comment)
• TanStack Router/Start have a routeTree.gen.ts which contains, well, the route tree, to route requests. It regenerates whenever the file tree changes.
• Cloudflare's wrangler CLI has a wrangler types command that generates type definitions for a Worker (generated from a user's Wrangler config), and also already generate a .wrangler directory for local dev testing when the dev server is started.
  • The Void SDK also creates a .void folder for TypeScript reasons, in addition to the .wrangler folder generated by the Cloudflare Vite plugin. Similar to Nuxt & Astro they also have void prepare to generate the .void folder.
• Vite itself has a vite optimize subcommand that runs the dependency optimization without starting the dev server. These usually should be run after node_modules is changed (which is 99% going to be after npm install).

Suggested solution

A new plugin hook, prepare(), can be introduced to generalize this. This hook could be called in any of these events:

• vite prepare subcommand (would be added to this update)
• vite dev HMR (when a tracked file is detected as changed, optional for DX purposes)
• vite build (start of build, optional since Vite itself doesn't type-check, which is most of the reason why these prepare commands exist)

This way, it satisfies all (or at least most) of the use cases mentioned above.

A neat add-on could allow for a --watch mode, but this is not required (and actually I'd prefer it if that wasn't added).

Alternative

The buildStart hook covers both the vite dev and vite build use cases mentioned above, since plugins can use this hook to generate these files. However, this still requires kicking off an entire build process to generate these files or require each framework to ship their own CLI for these things if they don't want to couple it to the build process.

A new vite prepare command and prepare() hook to generate these allow separation of the build process and the project types generation, making it much faster to get back to work.

Additional context

Security was raised as a concern and whilst this is a valid concern:

• The user would only be running this script if it was added to package.json#prepare and the user runs their dependency install command (which isn't ran automatically on clone, and can easily be checked and removed)
• The user would already be running plugin code upon vite dev/vite build anyways.
• As mentioned above, other frameworks already do this via their own CLIs.

As such I think this concern isn't really a blocker for implementation.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[teemingc]

SvelteKit also has a svelte-kit sync command which writes modules to disk, generates a tsconfig, and generates type definitions. We also use the npm prepare lifecycle script to automatically run this on dependency install. Aside from that, it's run specifically before type checking commands such as "check": "svelte-kit sync && tsc.

One concern might be around the timing of Vite resolving the user's tsconfig.json. Since we generate one that the user extends off of such as "extends": "$app/tsconfig", the generation of that module probably needs to run before anything that uses the tsconfig. Otherwise, it would error because the tsconfig to extend from doesn't exist yet.

[KTrain5169]

One concern might be around the timing of Vite resolving the user's tsconfig.json. Since we generate one that the user extends off of such as "extends": "$app/tsconfig", the generation of that module probably needs to run before anything that uses the tsconfig. Otherwise, it would error because the tsconfig to extend from doesn't exist yet.

I didn't think of this, but given the use cases are primarily stemming from TypeScript, I would imagine these hooks have to be called either immediately before config or after configResolved for it to work, depending on how Vite works when reading the supplied tsconfig.

(also I think nuxt generates an extendable tsconfig too)