feat(plugin-legacy): add a config option to exclude polyfills from the legacy bundle

[edmorrish]

Description

Adds an option to @vitejs/plugin-legacy to allow polyfill modules to be explicitly excluded from the legacy bundle, by passing through the option as configuration to @babel/preset-env's exclude option.

This addresses a use-case where the legacy plugin includes unwanted polyfill modules (for example when including the polyfill would incur a performance cost in certain environments and a faster alternative is available).

Additional context

N/A

---

What is the purpose of this pull request?

• [ ] Bug fix
• [X] New Feature
• [ ] Documentation update
• [ ] Other

Before submitting the PR, please make sure you do the following

• [X] Read the Contributing Guidelines, especially the Pull Request Guidelines.
• [X] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• [X] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• [X] Update the corresponding documentation if needed.
• [ ] Ideally, include relevant tests that fail without this PR but pass with it.

[edmorrish]

Is there something I should be doing here to kick off the review workflow?

[sapphi-red]

I have some questions.

• How are you injecting the alternative polyfill only to the legacy chunks?
• Mixing multiple polyfill library can cause conflict. Is there a reason just to swap one polyfill instead of the whole polyfill library? I wonder if adding support for https://github.com/babel/babel-polyfills would work.

[edmorrish]

I have some questions.

• How are you injecting the alternative polyfill only to the legacy chunks?

Thanks for taking a look. We aren't, in our use case we don't really have a need for the modern chunks since the vast majority of our deployment is to non-modern browsers.

• Mixing multiple polyfill library can cause conflict. Is there a reason just to swap one polyfill instead of the whole polyfill library? I wonder if adding support for https://github.com/babel/babel-polyfills would work.

For us it's about managing risk for specific quirks of our target devices, the vast majority of core-js@3 works with no problems on most devices, we've just had a specific case where one polyfill module seemed to be getting included when it wasn't being used, and seemed to be causing a performance issue, so we'd like to have the control to be able to manually exclude that one while we investigate the issue.

Adding babel-polyfills might help? ideally we'd just want access to be able to set config on the plugins so we can configure that or preset-env, but I can understand why you might not want to expose those lower level options.

[sapphi-red]

I can understand why you might not want to expose those lower level options.

We avoid adding new options. But what I am thinking is that the use case of this new option is too limited. IIUC (at least in this PR's implementation) this option can be only useful if:

1. the user only uses legacy chunks
2. the user wants to exclude some polyfills
3. the user can add alternative polyfills without conflicts or can skip adding them. (also the user should understand the risk of mixing polyfill libraries)

Patching the polyfill to be no-op feels more straight forward in this case.

one polyfill module seemed to be getting included when it wasn't being used, and seemed to be causing a performance issue

Would you expand this a bit more?

[edmorrish]

I can understand why you might not want to expose those lower level options.

We avoid adding new options. But what I am thinking is that the use case of this new option is too limited. IIUC (at least in this PR's implementation) this option can be only useful if:

1. the user only uses legacy chunks
2. the user wants to exclude some polyfills
3. the user can add alternative polyfills without conflicts or can skip adding them. (also the user should understand the risk of mixing polyfill libraries)

Patching the polyfill to be no-op feels more straight forward in this case.

one polyfill module seemed to be getting included when it wasn't being used, and seemed to be causing a performance issue

Would you expand this a bit more?

Sorry for a late reply, in the end we wrote our own plugin based off this one that gives us more granular control over which polyfills get included. Specifically on the one problematic polyfill, it was the esnext.json.parse polyfill from corejs, not sure why it flagged babel's feature detection to add it since we weren't using anything that needed it, but on devices without native Symbol support the polyfill completely replaced the native json.parse implementation with a non-native implementation which had massive performance degradation on some of our target browsers and devices.