Add `preTransform` and `postTransform` hooks

Description

I believe it would be best for Vite if #10671 was implemented as a plugin. It would keep inevitable bug reports out of the core repo. It’s up to the team to decide if they want to maintain it or let the community handle things. It doesn’t matter to me, as long as Vite is able to support other cache implementations. For example, someone might write a remote caching plugin or something with more granular invalidation.

To support #10671 as a plugin, we need some new plugin hooks.

Suggested solution

preTransform

This hook would be called before the following code: https://github.com/vitejs/vite/blob/18c71dcd2556ca395bd67ca7c720c1a435268332/packages/vite/src/node/server/transformRequest.ts#L237-L242

The first plugin to return a TransformResult object should end the plugin loop and prevent Vite’s transform pipeline from running for that file.

The hook would receive the following information:

• id: string
• file: string (the result of cleanUrl(id))
• ssr: boolean Since some plugins may run for SSR only
• mode: string Since some plugins may run for development/production only
• loadResult: Readonly<LoadResult> | null This will be null if no load hook returned a LoadResult so the code was loaded from disk.
• code: string
• map: Readonly<SourceMap> | null

postTransform

This hook would be called before the following code: https://github.com/vitejs/vite/blob/18c71dcd2556ca395bd67ca7c720c1a435268332/packages/vite/src/node/server/transformRequest.ts#L281

All plugins with a postTransform hook will be called (in parallel?). The return value is ignored.

The hook would receive everything that preTransform does plus the following:

• transformResult: Readonly<TransformResult>
• originalCode: string The code before transform hooks were applied.
• originalMap: Readonly<SourceMap> | null The sourcemap before transform hooks were applied.

Additional context

Note that these hooks will only run for transformRequest calls (at least for now).

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.

[patak-dev]

I think we would use Nx for build artifacts and maybe pre-bundled dependencies. That may be a good target that is costly to generate so you could get them from a remote cache. But for each individual module cache in your own source, it may be more performant to generate them than to download them from a remote cache.

[aleclarson]

We could rename these readFromCache and writeToCache to make it clear why they exist.

Alternatively, we could add a server.transformCache option that takes an object like this:

server: {
  transformCache: {
	read(id, { file, ssr, mode, loadResult, ...etc }) {
	},
	write(id, transformResult, { file, originalCode, ...etc }) {
	}
  }
}

This would make it clear that only one cache implementation should exist.