babel 7実践

先日使用しましたbabel7、特にメモをとります.原文はGitHubに発表された.
presets babel7では、以前の段階的な提案は廃棄されており、現在は一括して使用されている@babel/preset-env.だから、ここは少し面倒を省きました.webpack配置中preset-env協力babel-loader変換可能ES2015+構文です.また、公式にはtargetsターゲットブラウザを設定して互換性のある機能を決定することを推奨しています.例を挙げます.

module.exports = {
  presets: [
    [
      '@babel/preset-env',
      {
        targets: {
          ie: "11"
        }
      }
    ]
  ]
}

polyfill polyfillこれまでは新しいapi機能を導入するために使用されていた.私たちがよく使うpromise、Object.assignなどです.babel6およびそれまでは、入口にpolyfillを導入するだけでよい.しかし、これも問題をもたらし、一度に全体polyfillをロードし、非常に冗長である.使用したbabel7シンプルな構成でオンデマンドロードの目的を達成でき、手動で導入する必要もなくなりましたpolyfill.
useBuiltIns
そう、この新しいコンフィギュレーションアイテムを使えばオンデマンドロードが可能polyfill.次の3つの値を指定できます.
false
値がfalseの場合は、無駄に相当しますが、その場合は手動で全てのpolyfillを導入しなければなりません.
entry entryを使用する場合も、手動でpolyfill、すなわちimport '@babel/polyfill';を導入する必要があり、同時に全てのpolyfillを導入している.この配置項目は、なんだか役に立たないので、お兄さんが知っていればコメントエリアで一緒に議論してもいいです.
usage
値がusageの場合、導入不要polyfill、babel必要な機能が自動的にオンデマンドでロードされます.

{
  \\...
  useBuiltIns: 'usage'
}

コマンドラインにロード項目を印刷する必要がある場合は、debug:

{
  \\...
  useBuiltIns: 'usage',
  dubug: true
}

plugin-transform-runtime
たとえばclass（ ）を使用する場合、babelその前にヘルプ関数が追加されます.ソースコード:

// source code
class Test {}

コンパイル後:

"use strict";

function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

var Test = function Test() {
  _classCallCheck(this, Test);
};

コンパイル出力のコードには、helper関数が直接コードに埋め込まれていることがわかります.これしかないjsファイルがこれを使っているhelperなら問題ありません.しかし考えてみると、スクリプトファイルがたくさんあれば、どれもclass・、babelしかし、あなたがこんなに多くても、コンパイルされたファイルごとに同じhelper関数が含まれているので、冗長になります.幸いなことに、私たちは@babel/plugin-transform-runtimeと@babel/runtimeを使ってこの問題を解決することができます.次の構成を追加します.

plugins: [
  '@babel/plugin-transform-runtime'
]

このとき、上のコードをコンパイルすると、次のような結果が得られます.

"use strict";

var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault");

var _classCallCheck2 = _interopRequireDefault(require("@babel/runtime/helpers/classCallCheck"));

var Test = function Test() {
  (0, _classCallCheck2.default)(this, Test);
};

この場合は直接helper関数をコードに埋め込むのではなくrequire共通ロードhelperを使用します.
使用polyfillやはりruntime

他人に配布するためのツールやライブラリには、@babel/runtimeが適しています.@babel/polyfill全体の環境を汚染するため、他の人があなたの倉庫に導入すると不要な汚染をもたらす可能性があります.

そして@babel/runtime・・"foobar".includes("foo")など、いくつかの例示的な方法を提供することができない.また、自分で手動で導入する必要があります.

自分のアプリケーションについては、導入@babel/polyfillより良く、より包括的な機能を提供し、グローバル汚染を心配する必要はありません.しかし、上記のように、いくつかのhelper関数は、@babel/plugin-transform-runtimeプラグインを使用しないと冗長コードが導入されます.この両者を一緒に使用する場合、plugin-transform-runtimeを構成しなければ重複機能の導入はありません.
まとめ
以上述べたように,現在ではbabel7とwebpackの実践を終了とする.1.依存の追加

cnpm i --save-dev babel-loader @babel/core @babel/preset-env @babel/plugin-transform-runtime
// &
cnpm i --save @babel/polyfill @babel/runtime

2.webpack配置

module.exports = {
  // ...
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: 'babel-loader',
        exclude: /node_modules/
      }
    ]
  }
};

3.babel以下は自分のアプリケーション項目での構成です.

// babel.config.js
module.exports = {
  presets: [
    [
      '@babel/preset-env',
      {
        useBuiltIns: 'usage',
        targets: {
          ie: 10 //              
        },
        debug: true,
        // corejs        ，corejs 2 3    
        //           core-js，    cnpm i core-js@2 --save
        corejs: 2
      }
    ]
  ],
  plugins: [
    '@babel/plugin-transform-runtime'
  ]
};

他の人に配布するツールまたはライブラリは、次の構成を使用できます.

// babel.config.js
module.exports = {
  presets: [
    '@babel/preset-env'
  ],
  plugins: [
    [
      '@babel/plugin-transform-runtime',
      {
        corejs: 2
        // ...
      }
    ]
  ]
};