Which babel settings are suitable for exporting a library?

Viewed 232

I am new to Babel+Webpack and have some confusion regarding .babelrc configuration.

FIRST CONFIGURATION

{
    "presets": [
        [
            "@babel/env",
            {
                "modules": false,
                "useBuiltIns": "usage",
                "targets": "> 0.25%, not dead",
                "corejs": {
                    "version": 3,
                    "proposals": true
                }
            }
        ]
    ],
    "plugins": [
        "@babel/transform-runtime"
    ]
}

SECOND CONFIGURATION:

{
    "presets": [
        [
            "@babel/env",
            {
                "modules": false,
            }
        ]
    ],
    "plugins": [
        [
            "@babel/plugin-transform-runtime", //target environment are not supported
             {
                 "corejs": 3,
                 "helpers": true,
                 "regenerator": true
             }
        ]
    ]
}

Facts that are true for second configuration's are:

  1. Increased bundle size
  2. Core-js-pure will include ponyfills that will not pollute global environment.

My question is we are going to export a "umd" library for public use with a Library Name "XYZ" and i am confused which of the above settings are suitable as one thing really confuse me is that if the bundle i.e created at the end is minified and built completely on esm pattern(use-strict mode) and for public use they can access like "XYZ.method()", then how the second configuration is suitable and it stop polluting global namespace.

Can anyone explain me with an example and help me clearing this concept?

2 Answers

Ran into this myself, in the past. Honestly, Webpack is terrible with anything that exports more than a single default, which is why you see most libraries use Rollup or Parcel for bundling.

For libraries Rollup is a much better option than WebPack.

This a good starting point.

https://github.com/rollup/rollup-starter-lib

If you must use webpack, avoid using regenerater, as it adds a lot of bloat to the output of Babel, if you code needs it, then the consuming app should include it, so you don’t end up having it twice in the end app

Related