Proposal having two bundlers in one .size-limit.json

[JPeer264]

First thanks a lot for the great tool.

I do have a feature request (couldn't find similar issues on this). It might be a little tough, as I saw that the plugins are auto-loaded.

Status quo

Now when having a .size-limit.json with couple of configs then it will use the bundler which is installed, e.g. @size-limit/webpack. This works fine when all configs need to be build with webpack.

However, when adding @size-limit/esbuild as well, then everything will be bundled with esbuild and there is no way of changing that. Also the webpack: boolean, config is slightly confusing when there is the option to also have esbuild. It is actually also stated that esbuild is the default bundler, and that is ok.

Proposal

It'd be nice, when both bundlers are installed, that it is still possible to choose which config uses which bundler. E.g. having this as option: bundler: 'webpack' | 'esbuild' | false (false would be the same as webpack: false, or a potential esbuild: false). In theory this can then also support other bundlers/plugins if there would be any in the future.

// .size-limit.js

module.exports = [
  {
    name: 'first-package',
    bundler: 'esbuild',
  },
  {
    name: 'second-package',
    bundler: 'webpack',
  },
];

It'd be even crazier if people could use their own bundler if they want to:

// .size-limit.js

const esbuildPlugin = require('@size-limit/esbuild');
const theirOwnPlugin = require('./size-limit-rolldown');

module.exports = [
  {
    name: 'first-package',
    bundler: esbuildPlugin,
  },
  {
    name: 'second-package',
    bundler: theirOwnPlugin,
  },
];

[ai]

1. Can you explain your use case for it? I prefer to add features only if real users need them.
2. We can use disablePlugins to reduce number of the changes in the internal architecture.
3. Very likely that you will need to send PR, the feature is too rare for me :D

[JPeer264]

1. We do have a lot of SDKs and some of them require to be built with Webpack to represent the correct size (for now at least). With Cloudflare Workers this changes, as their final build will be bundled with esbuild. In order to show the correct bundle size we need to use esbuild for our Cloudflare SDK (I opened a PR on our side, and it shows the correct size for Cloudflare, but it should not affect the others)
2. That is a great idea. I would assume it would be for every entry and it would be an array of strings: disablePlugins: string[], right?
3. I'm happy to add a PR. Just let me know what you think is the best for your library.

[ai]

I would assume it would be for every entry and it would be an array of strings: disablePlugins: string[], right?

Yes