Allow third-party plugins to access css and asset dependency info

[ElMassimo]

Clear and concise description of the problem

The vite:manifest, vite:build-html, and vite:build-import-analysis plugins are accessing internal state from other plugins such as:

• chunkToEmittedCssFileMap: managed by the vite:css-post plugin, maps output chunks to emitted css files
• chunkToEmittedAssetsMap: managed by the vite:asset plugin, maps output chunks to emitted asset files

Also, vite:css-post is using registerAssetToChunk internally shared by vite:asset.

This state is necessary to infer the non-JS dependencies of individual chunks, and would be useful for third-party plugins such as those in Astro, îles, Vite Ruby, Laravel Vite, etc.

Suggested solution

Opening this issue to keep the conversation moving.

It would be nice to encapsulate the internals to simplify maintenance and future refactoring, but any change that exposes the data mentioned above would enable third-party plugins to achieve their goals.

Possible Implementations

Covering a few options we've talked about, some of these are not desirable:

Extend OutputChunk data

To include css and assets dependencies.

This way, we are making this data an explicit part of the dependency graph.

See implementation in #6629.

Extend the PluginContext API

Add additional methods to the PluginContext API that allow accessing the data (akin to getFileName):

this.cssFilesForChunk(chunk)
this.assetFilesForChunk(chunk)

ResolvedConfig functions

Have each plugin inject methods in ResolvedConfig that can provide the necessary functionality without exposing the internal data structures:

resolvedConfig.cssFilesForChunk(chunk)

Downsides

Too much responsibility for ResolvedConfig, poor maintainability.

Per-Plugin API

Expose an api in the vite:css-post and vite:asset plugins with respective functions to map chunks to files, and to register new dependencies.

Downsides

Requires third-party plugins to obtain the ResolvedConfig, filter plugins by name, and obtain the relevant one.

The name of the plugin becomes an external-facing API, which is fragile.

Single API Plugin

Similar to the previous, but instead centralize all internal APIs in a single plugin:

{
  name: 'vite:internal-api',
  get api () { return internalApi },
}

Downsides

Each internal plugin must extend this API, the exposed methods would depend on which plugins are active for the current mode (development vs build) or configuration.

Additional context

• Initial Discord Discussion
• Recent Discord Discussion

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.

[aleclarson]

See #6629

[bluwy]

@ElMassimo Is this fixed with #6629 merged?

[ElMassimo]

Hi @bluwy! Yes, thought this issue was linked to the PR, thanks for noticing!

Closed by #6629.