Allow users to apply plugins to and customise the pre-bundling process

This is to provide a common issue for various discussions.

• Prior PRs: #2991, #2886
• PRs/issues that could instead be solved by users using an option from this proposal: #2861, #1884, #2357
• Related discussions: #3094, #2349, #2511, #2238, #2922
• + miscellaneous disussions in Vite Land (cc @ggoodman)

Motivation / Use cases

1. Plugin ecosystem Enable developers to create and use plugins that apply before prebundling

2. Dependency patching Many dependencies have compatibility issues with esbuild. These historically have worked with other bundlers due to them being less strict or due to non-standard behaviour. These can often be unmaintained, blocking users from switching to Vite until they migrate away from such deps.

   • A workaround: patch-package – but this unfortunately does not work with pnpm
   • Adding dependencies to optimizeDeps.exclude – but since you’re using this with dependencies that have compatibility issues, it often does not work since other issues require bundling or further fixes.
   • optimizeDeps.exclude + running esbuild separately for certain deps - here’s a proof of concept for a customOptimizeDeps plugin, which is my current workaround for this use case.

3. Non-standard setups It would be easier to migrate to Vite if you could work around issues such as #1884 or #2861 using custom options/a plugin. These may not be recommended setups, but reduce friction when proposing a switch to a new build tool. Vite would not have to support such use cases natively, but would provide a useful escape hatch for those who need it.

Suggested solution

• Provide a plugin hook that runs before pre-bundling, but doesn’t require the user to opt-out of optimising dependencies. This would be especially valuable for plugin authors who want to hook into transforming dependencies before esbuild has touched them. This should cover many use cases, including patching dependencies. The advantage is that these plugins can be customised to apply to build, serve, or both, unlike esbuild plugins which would run only on serve (as the transform API doesn’t support plugins). They also would stay compatible if esbuild is replaced with another pre-bundling setup, a concern that @patak-js expressed during a conversation in Vite Land.

• Even with pre-pre-bundling plugins, we should nevertheless allow a custom esbuild config, similar to how we allow a custom rollup config if users need to further customise the build. This is something I outlined in #2991, but it could be adapted a bit. For example, we could expose it as a custom hook instead, something like unstable_resolveEsbuildConfig, which would make it clear that it is an escape hatch and not stable.

Alternative

An entirely different approach for the esbuild config options could be to extract the current prebundling plugin fully, and allow users to replace it with their own plugin. However, this would likely be unnecessarily complex.

Additional context

N/A

cc @qnp

[nihalgonsalves]

@qnp

To my point of view, as dev-server and build modes do not depend on the same technology (esbuild vs rollup), I think we should provide both ways to configure either one or the other explicitly – as problems and edge cases we would like to cover will be specifically for one given tool and not the other on

I agree - that’s why I proposed both additions. If something is not specific to esbuild/rollup, it would be recommended to use a generic plugin that applies before the optimisation process, so that it works for both modes. But if a user needs to customise the esbuild/rollup config for something, that should also be allowed.

If I understand you @nihalgonsalves quite well, the point of using the plugin solution is to provide a way for plugin authors to cover these cases without using the vite config ?

Yes, to be able to extend functionality without needing to add niche use cases/legacy support/etc to Vite, or fork/patch Vite.

[bluwy]

I think this is resolved with optimizeDeps.esbuildOptions, optimizeDeps.esbuildOptions.plugins and optimizeDeps.extensions. The other points seems to relate to #4921. I’ll go ahead and close this then.