feat(esbuild): add user esbuild plugins support

[qnp]

Description

Quoting esbuild-plugin-alias:

Sometimes it's useful to have dynamic imports that resolves into different files depending on some conditions (e.g. env variables).

In my case, I had to shim all internal Vuetify VIcon imports to replace it with a custom and improved component ZIcon. With vue-cli-3 and Webpack, all was fine. With Vite, I use this config:

// vite.config.js
  resolve: {
    alias: {
      '../VIcon': path.resolve(__dirname, 'src/components/ZIcon'),
      '../../VIcon': path.resolve(__dirname, 'src/components/ZIcon'),
    },
  },

Aliases are properly handled by rollup at compilation. However, they are not matched by esbuild (the Vuetify component is imported).
I thought about adding internally to Vite an import to esbuild-plugin-alias and plug to it the config aliases, but not sure about side effects and the versatility of this solution – I guess it is an edge case, and more profitable to all if esbuid’s plugin system is exposed.

Hence, I propose to add an entry esbuildPlugins to Vite config as such:

// vite.config.js
import alias from 'esbuild-plugin-alias';
export default {
  ...
  esbuildPlugins: [
    alias({
      '../VIcon': path.resolve(__dirname, 'src/components/ZIcon/index.js'),
      '../../VIcon': path.resolve(__dirname, 'src/components/ZIcon/index.js'),
    })
  ],
}

Additional context

Do you think it is the correct way to tackle the above mentioned issue ?

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.

[Shinigami92]

suggestion: IMO this should be part of ESBuildOptions and not its own property

[qnp]

Yes indeed, however it may introduce breaking changes, as Vite config esbuild option (ESBuildOptions) are passed directly to esbuild transform function, not to build function. See:

vite/packages/vite/src/node/plugins/esbuild.ts

Line 52 in 0dc6e37

...options

We could think about:

1. Split the actual esbuild config into:

esbuild: {
   transform: { /* the current `esbuild` options */ },
   build: { plugins: [/* the esbuild plugins */] },
},

but this is a breaking change

2. Keep the actual model and add plugins to it, or build.plugins to be clearer and allow for more flexibility in future developments:

esbuild: {
   /* actual options */,
   build: { plugins: [/* the esbuild plugins */] },
},

and do delete resolvedOptions.build in transformWithEsbuild function before passing the options.

I am not convinced about the second solution.

I think the first one is much more clear, and we could go a step further by:

3. using the root of ebuild options (as today) for include, exclude and jsxInject options (which are deleted from options before the latter object is passed to esbuild.transform – so doing so we avoid this deletion and directly pass options.transform to esbuild.transform(), while options.build are passed directly to esbuild.build() with an appropriate merge):

esbuild: {
   include: ...,
   exclude: ...,
   jsxInject: `import React from 'react'`,
   transform: {
     jsxFactory: 'h',
     jsxFragment: 'Fragment',
   },
   build: {
     plugins: [/* the esbuild plugins */],
     /* other future options */
   },
},

[Shinigami92]

🚀 I really like your proposal 👍

@patak-js (@antfu) What are your thoughts about this?

Also IMO a breaking change shouldn't hold us back for such an improvement because it may be more future-proof

[qnp]

Alright, if @patak-js and @antfu validate, I'll do the coding.
What is the roadmap for such a feature to be included in next minor ?
I'm pretty much impatient to use it ;-)

[nihalgonsalves]

I feel like since optimizeDeps is an entirely different build phase than the esbuild transform options, the settings should go into config.optimizeDeps. Here's a demonstration of that, perhaps this helps: #2991

I'd really like to get this functionality soon, since we're blocked by this in our conversion.