babel-polyfills: [preset-env] Add ability to error if polyfills are required

Feature Request

Some corejs polyfills are overly bloated (or have trivial alternatives in many situations) and it can be desirable to avoid the need for them. preset-env already has the ability to detect where polyfills would be required in code via useBuiltIns (and with more accuracy than a linter since it is the tool which actually adds the polyfill!)

Extending the existing concept of the exclude section to provide a way of forbidding individual polyfills would be useful for managing this:

{
  "useBuiltIns": "inline",
  "corejs": 3,
  "polyfills": {
    "web.url": "useBuiltIn", // or true
    "es.string.replace": "exclude",
    "web.immediate": "error"
  }
}

This would replace exclude (with a simple migration path) and has the advantage of having a less ambiguous name.

Unconfigured polyfills could default to either useBuiltIn (to match current behaviour and make it easier to adopt new polyfills) or error (to force developers to consider each newly required polyfill rather than blindly accepting it). I could see arguments for both defaults; not sure what’s best (though I personally would prefer an error default).

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (8 by maintainers)

Most upvoted comments

@jrylan If “any chat medium” is too vague you can contact him on our Slack (https://github.com/babel/babel-polyfills/issues/10#issuecomment-609097875).

I’m now marking these comments as off-topic to keep the discussion focused on the original issue.

nicolo-ribaudo on May 4, 2020

This thread seems to be focussing on transpilation of node_modules, but to clarify: when I originally raised this suggestion, it was on a project which does not transpile node_modules and uses inline mode (so any added polyfills wouldn’t affect node_modules anyway).

There already exists a feature (exclude) which silently omits polyfills. This request is simply to allow noisily omitting them, which should make potential issues more visible.

davidje13 on May 4, 2020

@jrylan find me on any chat medium and I’m happy to discuss it further; I find it perfectly reasonable to ask all module authors to transpile everything down to ES5. Correctness and “works” matters more than bundle size.

ljharb on May 4, 2020

I think this could be useful in two cases:

error is useful if you know that the polyfill for X is slow/big and you want to be sure not to write any code that would need it
if you are only polyfilling your own code (using usage-global or usage-pure, and not transpiling node_modules), then you can be confident that you don’t need some edge cases to be handled.

However, I think that this (or at least, error) could be implemented by adding a lower-level function option that is called whenever a polyfill is injected. This also satisfies other use cases that have been requested in various channels:

programmatically get a list of all the injected polyfills
automatically npm install new polyfills (<-- This is something I personally don’t like)

nicolo-ribaudo on May 2, 2020