メインコンテンツにスキップ

Babelの設定

Babelは設定可能です！他の多くのツールも同様の設定を持っています：ESLint (.eslintrc)、Prettier (.prettierrc)。

すべてのBabel API オプションが許可されています。ただし、オプションがJavaScriptを必要とする場合は、JavaScriptの設定ファイルを使用することをお勧めします。

どのようなユースケースですか？​

  • モノレポを使用していますか？
  • node_modulesをコンパイルしたいですか？

babel.config.jsonがおすすめです！

  • プロジェクトの一部だけに適用される設定が必要ですか？

.babelrc.jsonがおすすめです！

  • ガイ・フィエリがあなたのヒーローですか？

babel.config.json形式を使用することをお勧めします。

babel.config.json​

プロジェクトのルート（package.jsonがある場所）に、次の内容のbabel.config.jsonというファイルを作成します。

babel.config.json
{
  "presets": [...],
  "plugins": [...]
}

詳細な設定オプションについては、babel.config.jsonのドキュメントを参照してください。

.babelrc.json​

プロジェクト内に次の内容の.babelrc.jsonというファイルを作成します。

.babelrc.json
{
  "presets": [...],
  "plugins": [...]
}

詳細な設定オプションについては、.babelrcのドキュメントを参照してください。

package.json​

または、package.json内のbabelキーを使用して、.babelrc.jsonの設定を指定することもできます。

package.json
{
  "name": "my-package",
  "version": "1.0.0",
  "babel": {
    "presets": [ ... ],
    "plugins": [ ... ],
  }
}

JavaScript設定ファイル​

JavaScriptを使用して、babel.config.js(私たちがやっているように)や.babelrc.jsファイルを作成することもできます。

babel.config.js
module.exports = function (api) {
  api.cache(true);

  const presets = [ ... ];
  const plugins = [ ... ];

  return {
    presets,
    plugins
  };
}

Node.js APIにアクセスして、例えばプロセス環境に基づいた動的な設定を行うことも可能です。

babel.config.js
module.exports = function (api) {
  api.cache(true);

  const presets = [ ... ];
  const plugins = [ ... ];

  if (process.env["ENV"] === "prod") {
    plugins.push(...);
  }

  return {
    presets,
    plugins
  };
}

JavaScript設定ファイルの詳細については、専用のドキュメントを参照してください。

CLIを使用する (@babel/cli)​

シェル
babel --plugins @babel/plugin-transform-arrow-functions script.js

詳細な設定オプションについては、babel-cliのドキュメントを参照してください。

APIを使用する (@babel/core)​

JavaScript
require("@babel/core").transformSync("code", {
  plugins: ["@babel/plugin-transform-arrow-functions"],
});

詳細な設定オプションについては、babel-coreのドキュメントを参照してください。

Babelに、指定された入力パスの有効な設定を出力するように指示できます。


# *nix or WSL
BABEL_SHOW_CONFIG_FOR=./src/myComponent.jsx npm start

BABEL_SHOW_CONFIG_FORは絶対パスと相対パスのファイルパスの両方を受け入れます。相対パスの場合、cwdから解決されます。

Babelは、BABEL_SHOW_CONFIG_FORで指定された入力ファイルを処理すると、コンソールに有効な設定を出力します。以下は出力例です。

Babel configs on "/path/to/cwd/src/index.js" (ascending priority):
config /path/to/cwd/babel.config.json
{
  "sourceType": "script",
  "plugins": [
    "@foo/babel-plugin-1"
  ],
  "extends": "./my-extended.js"
}

config /path/to/cwd/babel.config.json .env["test"]
{
  "plugins": [
    [
      "@foo/babel-plugin-3",
      {
        "noDocumentAll": true
      },
    ]
  ]
}

config /path/to/cwd/babel.config.json .overrides[0]
{
  "test": "src/index.js",
  "sourceMaps": true
}

config /path/to/cwd/.babelrc
{}

programmatic options from @babel/cli
{
  "sourceFileName": "./src/index.js",
  "presets": [
    "@babel/preset-env"
  ],
  "configFile": "./my-config.js",
  "caller": {
    "name": "@babel/cli"
  },
  "filename": "./src/index.js"
}

Babelは、優先度の低い順に並べられた有効な設定ソースを出力します。上記の例を使用すると、優先度は次のようになります。

babel.config.json < .babelrc < programmatic options from @babel/cli

言い換えれば、babel.config.jsonは.babelrcで上書きされ、.babelrcはプログラムによるオプションで上書きされます。

設定ソースごとに、Babelは適用可能な設定項目(例えば、overridesやenv)を優先度の低い順に出力します。一般的に、各設定ソースには少なくとも1つの設定項目（設定のルートコンテンツ）があります。overridesまたはenvを設定した場合、Babelはそれらをルートに出力せず、代わりに.overrides[index]というタイトルの別の設定項目を出力します。ここで、indexは項目の位置です。これにより、項目が入力に対して有効かどうか、どの設定を上書きするかがわかります。

入力がignoreまたはonlyで無視される場合、Babelはこのファイルが無視されたことを出力します。

Babelが設定項目をマージする方法​

Babelの設定マージは比較的簡単です。オプションが存在し、その値がundefinedでない場合、オプションは既存のオプションを上書きします。ただし、いくつかの特別なケースがあります。

  • assumptions、parserOpts、およびgeneratorOptsについては、オブジェクトは置き換えられるのではなく、マージされます。
  • pluginsとpresetsについては、プラグイン/プリセットオブジェクト/関数自体のIDとエントリの名前に基づいて置き換えられます。

オプション（プラグイン/プリセットを除く）のマージ​

例として、次の設定を考えてみましょう。

JavaScript
{
  sourceType: "script",
  assumptions: {
    setClassFields: true,
    iterableIsArray: false
  },
  env: {
    test: {
      sourceType: "module",
      assumptions: {
        iterableIsArray: true,
      },
    }
  }
};

NODE_ENVがtestの場合、sourceTypeオプションは置き換えられ、assumptionsオプションはマージされます。有効な設定は次のようになります。

JavaScript
{
  sourceType: "module", // sourceType: "script" is overwritten
  assumptions: {
    setClassFields: true,
    iterableIsArray: true, // assumptions are merged by Object.assign
  },
}

プラグイン/プリセットのマージ​

例として、次の設定を考えてみましょう。

JavaScript
plugins: [
  './other',
  ['./plug', { thing: true, field1: true }]
],
overrides: [{
  plugins: [
    ['./plug', { thing: false, field2: true }],
  ]
}]

overrides項目は、トップレベルのオプションの上にマージされます。重要なのは、plugins配列全体がトップレベルのものを置き換えるだけではないということです。マージロジックは、"./plug"が両方の場合で同じプラグインであると認識し、{ thing: false, field2: true }が元のオプションを置き換え、結果として次の設定になります。

JavaScript
plugins: [
  './other',
  ['./plug', { thing: false, field2: true }],
],

マージはID+名前に基づいているため、同じplugins/presets配列内で同じ名前の同じプラグインを2回使用するとエラーと見なされます。たとえば、

JavaScript
plugins: ["./plug", "./plug"];

これはplugins: ['./plug']と同じであるため、エラーと見なされます。さらに、

JavaScript
plugins: [["./plug", { one: true }], ["./plug", { two: true }]];

これもエラーと見なされます。なぜなら、2番目のプラグインは常に最初のプラグインを置き換えるからです。

実際にプラグインの2つの個別のインスタンスを作成したい場合は、それぞれに名前を割り当てて区別する必要があります。例えば、

JavaScript
plugins: [
  ["./plug", { one: true }, "first-instance-name"],
  ["./plug", { two: true }, "second-instance-name"],
];

各インスタンスに一意の名前が付けられ、一意のIDが与えられているためです。