** REFERENCE Documents: Do you really know how to use Babel?

In the development process, if we write code with ES6 syntax, there are many syntaxes such as async, array. isArray, object. assign, and so on, which are not supported by earlier browsers. To ensure that the ES6 syntax we wrote would run across both the old and new clients, we needed to introduce Polyfill to inject the new syntax globally.

The result of not importing is: the page reports an error



How to introduce polyfill?

Method a,

Import polyfill globally: import ‘@babel/polyfill’ in the webpack entry file;

It simulates our application execution environment with perfect ES6 + support, since both browser and Node environments support es6+ differently. It is overloaded global variables (um participant: Promise), and a static method on the prototype and the class (um participant: Array. Prototype. Reduce/Array. The from), so as to achieve support for es6 +. Unlike Babel-Runtime, babel-Polyfill is introduced into your project once, like the React package, and compiled into production with the project code.

Cons: Introducing @babel/polyfill globally may import unwanted polyfills in your code, resulting in a larger packaging volume

Improvement: Using useBuiltIns, env will automatically determine what polyfill we want to use, depending on our environment, and the size of the packaged code will be much smaller, but you need to configure useBuiltIns, and you need to install Babel-Polyfill, And the import. It will enable a plug-in that replaces your import ‘babel-Polyfill’, not as a whole, but as a separate polyfill depending on your configured environment and individual needs.

Usage:

{

  "presets": [["@babel/env",
      {
        "modules": "commonjs"// Set the ES6 module format to commonJS by default"useBuiltIns": "usage",}]],}Copy the code

When “useBuiltIns”: “Usage” is enabled, the size of the packaged file is significantly reduced. From 857 KiB = 610 KiB

Note that useBuiltIns: False packs the same as useBuiltIns: Entry. After using ‘useBuiltIns: ‘usage’, you do not need to manually import ‘@babel/polyfill’ in the import file, otherwise you will get the following warning:

When setting `useBuiltIns: ‘usage’`, polyfills are automatically imported when needed. Please remove the `import ‘@babel/polyfill’` call or use `useBuiltIns: ‘entry’` + `import ‘@babel/polyfill’`instead.

Method 2: Configure in the babelrc file@babel/transform-runtimeĀ 

{

  "presets": [["@babel/env",
      {
        "modules": "commonjs"// Set ES6 module to commonjs}]],"plugins": [
    "@babel/transform-react-jsx"// If you need to support JSX, this should be installed separately."@babel/transform-runtime"]},Copy the code

Advantages: Transform-Runtime checks if the API needs to be rewritten, and then writes the required API as needed. This greatly reduces the size of the packaged files, and the Transform-Runtime does not contaminate the native objects, methods, or other polyfills. Therefore, transform-Runtime is more suitable for development kits and libraries. On the one hand, the size is small enough. On the other hand, users (developers) will not pollute the global native methods and cause side effects by referencing our tools and packages.

Disadvantages: babel-plugin-transform-Runtime does not handle the newly added methods on instance, such as includes, filter, fill, etc. For example, I write a filter method in my code that works perfectly in my browser. But the test sister a test, found that she can not use a certain function on the browser, debugging found that filter is not supported, uncomfortable not šŸ˜£

conclusion

  • Package volume: globally introduced @babel/polyfill + “useBuiltIns”: “usage” method, can be based on the environment to determine which prolyfill to introduce, this can effectively reduce the volume of packaged code; Babel-polyfill is configured with an execution environment to see which polyfills you need, and transform-Runtime, which discovers which polyfills our code needs, overwrites which polyfills. So transform-Runtime packaging volume is less than @babel/polyfill + “useBuiltIns”: “usage”.
  • Global contamination: @babel/polyfill is violent and overwrites native objects and methods in code, whereas transform-Runtime does not.
  • Scope of polyfill: the babel-plugin-transform-runtime method is not handled, such as includes, filter, fill, etc