Skip to main content

配置文件

配置文件类型

¥Configuration File Types

Babel 有两种并行的配置文件格式,可以一起使用,也可以单独使用。

¥Babel has two parallel config file formats, which can be used together, or independently.

History
版本变化
v7.21.0支持 .babelrc.ctsbabel.config.cts(实验性)
v7.8.0支持 .babelrc.mjsbabel.config.mjs
v7.7.0支持 .babelrc.json.babelrc.cjsbabel.config.jsonbabel.config.cjs
  • 项目范围的配置

    ¥Project-wide configuration

    • babel.config.* 文件,具有以下扩展名:.json.js.cjs.mjs.cts

      ¥babel.config.* files, with the following extensions: .json, .js, .cjs, .mjs, .cts.

  • 文件相关配置

    ¥File-relative configuration

    • .babelrc.* 文件,具有以下扩展名:.json.js.cjs.mjs.cts

      ¥.babelrc.* files, with the following extensions: .json, .js, .cjs, .mjs, .cts.

    • .babelrc 文件,没有扩展名。

      ¥.babelrc file, with no extension.

    • package.json 文件,带有 "babel" 密钥。

      ¥package.json files, with a "babel" key.

项目范围的配置

¥Project-wide configuration

Babel 7.x 中的新功能,Babel 有一个 "root" 目录的概念,默认为当前工作目录。对于项目范围的配置,Babel 会自动在这个根目录中搜索一个 babel.config.json 文件,或者使用 支持的扩展 的等效文件。或者,用户可以使用显式 "configFile" 值来覆盖默认配置文件搜索行为。

¥New in Babel 7.x, Babel has a concept of a "root" directory, which defaults to the current working directory. For project-wide configuration, Babel will automatically search for a babel.config.json file, or an equivalent one using the supported extensions, in this root directory. Alternatively, users can use an explicit "configFile" value to override the default config file search behavior.

因为项目范围的配置文件与配置文件的物理位置是分开的,所以它们非常适合必须广泛应用的配置,甚至允许插件和预设轻松应用于 node_modules 或符号链接包中的文件,这在传统上是相当痛苦的在 Babel 6.x 中配置。

¥Because project-wide config files are separated from the physical location of the config file, they can be ideal for configuration that must apply broadly, even allowing plugins and presets to easily apply to files in node_modules or in symlinked packages, which were traditionally quite painful to configure in Babel 6.x.

这个项目范围配置的主要缺点是,因为它依赖于工作目录,如果工作目录不是大仓根目录,那么在大仓中使用会更加痛苦。有关如何在该上下文中使用配置文件的示例,请参阅 大仓 文档。

¥The primary downside of this project-wide config is that, because it relies on the working directory, it can be more painful to use in monorepos if the working directory is not the monorepo root. See the monorepo documentation for examples of how to use config files in that context.

也可以通过将 "configFile" 设置为 false 来禁用项目范围的配置。

¥Project-wide configs can also be disabled by setting "configFile" to false.

文件相关配置

¥File-relative configuration

Babel 加载 .babelrc.json 文件,或使用 支持的扩展 的等效文件,通过搜索从正在编译的 "filename" 开始的目录结构(受以下警告限制)。这可能很强大,因为它允许你为包的子部分创建独立的配置。文件相关配置也是项目范围配置值之上的 merged,这使得它们可能对特定的覆盖有用,尽管这也可以通过 "overrides" 来完成。

¥Babel loads .babelrc.json files, or an equivalent one using the supported extensions, by searching up the directory structure starting from the "filename" being compiled (limited by the caveats below). This can be powerful because it allows you to create independent configurations for subsections of a package. File-relative configurations are also merged over top of project-wide config values, making them potentially useful for specific overrides, though that can also be accomplished through "overrides".

使用文件相对配置时需要考虑一些边缘情况:

¥There are a few edge cases to consider when using a file-relative config:

  • 一旦找到包含 package.json 的目录,搜索将停止,因此相对配置仅适用于单个包中。

    ¥Searching will stop once a directory containing a package.json is found, so a relative config only applies within a single package.

  • 正在编译的 "filename" 必须在 "babelrcRoots" 包内,否则将完全跳过搜索。

    ¥The "filename" being compiled must be inside of "babelrcRoots" packages, or else searching will be skipped entirely.

这些警告意味着:

¥These caveats mean that:

  • .babelrc.json 文件只适用于自己包内的文件

    ¥.babelrc.json files only apply to files within their own package

  • 不属于 Babel 的 'root' 的包中的 .babelrc.json 文件将被忽略,除非你选择使用 "babelrcRoots"

    ¥.babelrc.json files in packages that aren't Babel's 'root' are ignored unless you opt in with "babelrcRoots".

有关如何配置具有许多包的大仓的更多讨论,请参阅 大仓 文档。也可以通过将 "babelrc" 设置为 false 来禁用文件相关配置。

¥See the monorepo documentation for more discussion on how to configure monorepos that have many packages. File-relative configs can also be disabled by setting "babelrc" to false.

6.x 与 7.x .babelrc 加载

¥6.x vs 7.x .babelrc loading

来自 Babel 6.x 的用户可能会遇到这两种极端情况,这在 Babel 7.x 中是新的。添加了这两个限制以解决 Babel 6.x 中的常见足枪问题:

¥Users coming from Babel 6.x will likely trip up on these two edge cases, which are new in Babel 7.x. These two restrictions were added to address common footguns in Babel 6.x:

  • .babelrc 文件应用于 node_modules 依赖,通常是出乎意料的。

    ¥.babelrc files applied to node_modules dependencies, often unexpectedly.

  • 当人们期望 .babelrc 文件表现得像正常依赖时,.babelrc 文件未能应用于符号链接的 node_modules

    ¥.babelrc files failed to apply to symlinked node_modules when people expected them to behave like normal dependencies.

  • 会检测到 node_modules 依赖中的 .babelrc 文件,即使它们中的插件和预设通常没有安装,甚至可能在 Babel 编译文件的版本中无效。

    ¥.babelrc files in node_modules dependencies would be detected, even though the plugins and presets inside they were generally not installed, and may not even be valid in the version of Babel compiling the file.

这些情况主要会给具有大仓结构的用户带来问题,因为如果你有

¥These cases will primarily cause issues for users with a monorepo structure, because if you have

.babelrc
packages/
mod1/
package.json
src/index.js
mod2/
package.json
src/index.js

配置现在将被完全忽略,因为它跨越了包边界。

¥the config will now be entirely ignored, because it is across a package boundary.

一种替代方法是在每个使用 "extends" 的子包中创建一个 .babelrc

¥One alternative would be to create a .babelrc in each sub-package that uses "extends" as

.babelrc.json
{ "extends": "../../.babelrc" }

不幸的是,这种方法可能有点重复,并且根据 Babel 的使用方式,可能需要设置 "babelrcRoots"

¥Unfortunately, this approach can be a bit repetitive, and depending on how Babel is being used, could require setting "babelrcRoots".

鉴于此,将 .babelrc 重命名为 项目范围 "babel.config.json" 可能更可取。如上面项目范围部分所述,这可能需要显式设置 "configFile" 因为如果工作目录不正确,Babel 将找不到配置文件。

¥Given that, it may be more desirable to rename the .babelrc to be a project-wide "babel.config.json". As mentioned in the project-wide section above, this may then require explicitly setting "configFile" since Babel will not find the config file if the working directory isn't correct.

支持的文件扩展名

¥Supported file extensions

Babel 可以使用 Node.js 原生支持的任何文件扩展名进行配置,如 配置文件类型 部分所述:

¥Babel can be configured using any file extension natively supported by Node.js, as mentioned in Configuration File Types section:

  • babel.config.json.babelrc.json 被解析为 JSON5 并且应该包含一个匹配 Babel 接受的 选项 格式的对象。自 v7.7.0 以来,它们一直受到支持。

    ¥babel.config.json and .babelrc.json are parsed as JSON5 and should contain an object matching the options format that Babel accepts. They have been supported since v7.7.0.

    我们建议尽可能使用此文件类型:如果你有复杂的配置(在构建时是有条件的或以其他方式计算的),那么 JS 配置文件会很方便。但是,缺点是 JS 配置的静态可分析性较差,因此对可缓存性、linting、IDE 自动补齐等有负面影响。由于 babel.config.json.babelrc.json 是静态 JSON 文件,它允许其他使用 Babel 的工具(例如打包器)缓存 Babel 安全的结果,这可能是一个巨大的构建性能胜利。

    ¥We recommend using this file type wherever possible: JS config files are handy if you have complex configuration that is conditional or otherwise computed at build time. However, the downside is that JS configs are less statically analyzable, and therefore have negative effects on cacheability, linting, IDE autocomplete, etc. Since babel.config.json and .babelrc.json are static JSON files, it allows other tools that use Babel such as bundlers to cache the results of Babel safely, which can be a huge build performance win.

  • babel.config.cjs.babelrc.cjs 允许你使用 module.exports 将你的配置定义为 CommonJS。自 v7.7.0 以来,它们一直受到支持。

    ¥babel.config.cjs and .babelrc.cjs allow you to define your configuration as CommonJS, using module.exports. They have been supported since v7.7.0.

  • babel.config.mjs.babelrc.mjs 使用原生 ECMAScript 模块。它们受 Node.js 13.2+(或通过 --experimental-modules 标志的旧版本)支持。请记住原生 ECMAScript 模块是异步的(这就是为什么 import() 总是返回一个 promise!):因此,.mjs 配置文件在同步调用 Babel 时会抛出异常。自 v7.8.0 以来,它们一直受到支持。

    ¥babel.config.mjs and .babelrc.mjs use native ECMAScript modules. They are supported by Node.js 13.2+ (or older versions via the --experimental-modules flag). Please remember that native ECMAScript modules are asynchronous (that's why import() always returns a promise!): for this reason, .mjs config files will throw when calling Babel synchronously. They have been supported since v7.8.0.

  • 当你的 package.json 文件包含 "type": "module" 选项时,babel.config.js.babelrc.js 的行为类似于 .mjs 等效项,否则它们与 .cjs 文件完全相同。

    ¥babel.config.js and .babelrc.js behave like the .mjs equivalents when your package.json file contains the "type": "module" option, otherwise they are exactly the same as the .cjs files.

  • babel.config.cts.babelrc.cts 允许你将配置定义为 Typescript + CommonJS。你必须安装 @babel/preset-typescript,或者使用 ts-node 运行 Babel。

    ¥babel.config.cts and .babelrc.cts allow you to define your configuration as Typescript + CommonJS. You must either install @babel/preset-typescript, or run Babel using ts-node.

注意

🚧 此功能是实验性的。目前还无法使用 babel.config.tsbabel.config.mts 文件,有待 Node.js ESM 加载器 API 的稳定。

¥🚧 This functionality is experimental. It's not possible yet to use babel.config.ts and babel.config.mts files, pending stabilization of the Node.js ESM loader API.

JavaScript 配置文件既可以导出一个对象,也可以导出一个函数,调用该函数将返回生成的配置。函数返回配置被赋予了一些特殊的权力,因为它们可以访问 Babel 本身公开的 API。有关详细信息,请参阅 配置函数接口

¥JavaScript configuration files can either export an object, or a function that when called will return the generated configuration. Function-returning configs are given a few special powers because they can access an API exposed by Babel itself. See Config Function API for more information.

注意

出于兼容性原因,.babelrc.babelrc.json 的别名。

¥For compatibility reasons, .babelrc is an alias for .babelrc.json.

大仓

¥Monorepos

Monorepo 结构的存储库通常包含许多包,这意味着它们经常遇到 文件相关配置 和配置文件加载中提到的警告。本节旨在帮助用户了解如何处理大仓配置。

¥Monorepo-structured repositories usually contain many packages, which means that they frequently run into the caveats mentioned in file-relative configuration and config file loading in general. This section is aimed at helping users understand how to approach monorepo configuration.

对于大仓设置,要理解的核心是 Babel 将你的工作目录视为其逻辑 "root",如果你想在特定子包中运行 Babel 工具而不将 Babel 应用到整个 repo,这会导致问题。

¥With monorepo setups, the core thing to understand is that Babel treats your working directory as its logical "root", which causes problems if you want to run Babel tools within a specific sub-package without having Babel apply to the repo as a whole.

另外,决定你是要使用 .babelrc.json 文件还是只使用中央 babel.config.json 文件也很重要。.babelrc.json 文件不需要像在 Babel 6 中那样用于特定于子文件夹的配置,因此在 Babel 7 中通常不需要它们,有利于 babel.config.json

¥Separately, it is also important to decide if you want to use .babelrc.json files or just a central babel.config.json. .babelrc.json files are not required for subfolder-specific configuration like they were in Babel 6, so often they are not needed in Babel 7, in favor of babel.config.json.

babel.config.json 文件

¥Root babel.config.json file

任何大仓结构的第一步应该是在存储库根目录中创建一个 babel.config.json 文件。这确立了 Babel 的核心概念,即存储库的基本目录。即使你想使用 .babelrc.json 文件来配置每个单独的包,重要的是要有一个存储库级别选项的位置。

¥The first step in any monorepo structure should be to create a babel.config.json file in repository root. This establishes Babel's core concept of the base directory of your repository. Even if you want to use .babelrc.json files to configure each separate package, it is important to have as a place for repo-level options.

你通常可以将所有 repo 配置放在根 babel.config.json 中。使用 "overrides",你可以轻松地指定仅适用于存储库的某些子文件夹的配置,这通常比在存储库中创建许多 .babelrc.json 文件更容易遵循。

¥You can often place all of your repo configuration in the root babel.config.json. With "overrides", you can easily specify configuration that only applies to certain subfolders of your repository, which can often be easier to follow than creating many .babelrc.json files across the repo.

你可能会遇到的第一个问题是,默认情况下,Babel 期望从设置为 "root" 的目录中加载 babel.config.json 文件,这意味着如果你创建 babel.config.json,但在单个包中运行 Babel,例如

¥The first issue you'll likely run into is that by default, Babel expects to load babel.config.json files from the directory set as its "root", which means that if you create a babel.config.json, but run Babel inside an individual package, e.g.

Shell
cd packages/some-package;
babel src -d dist

在这种情况下使用的 "root" Babel 不是你的大仓根,它无法找到 babel.config.json 文件。

¥the "root" Babel is using in that context is not your monorepo root, and it won't be able to find the babel.config.json file.

如果你的所有构建脚本都相对于你的存储库根目录运行,那么一切应该已经工作了,但是如果你是从一个子包中运行你的 Babel 编译过程,你需要告诉 Babel 在哪里寻找配置。有几种方法可以做到这一点,但推荐的方法是使用 "upward""rootMode" 选项,这将使 Babel 从工作目录向上搜索你的 babel.config.json 文件,并将其位置用作 "root" 值。

¥If all of your build scripts run relative to your repository root, things should already work, but if you are running your Babel compilation process from within a subpackage, you need to tell Babel where to look for the config. There are a few ways to do that, but the recommended way is the "rootMode" option with "upward", which will make Babel search from the working directory upward looking for your babel.config.json file, and will use its location as the "root" value.

测试你的配置是否被检测到的一种有用方法是,如果它是 babel.config.json JavaScript 文件,则在其中放置一个 console.log() 调用:日志将在 Babel 第一次加载它时执行。

¥One helpful way to test if your config is being detected is to place a console.log() call inside of it if it is a babel.config.json JavaScript file: the log will execute the first time Babel loads it.

设置此值的方式因项目而异,但这里有几个示例:

¥How you set this value varies by project, but here are a few examples:

CLI

Shell
babel --root-mode upward src -d lib

@babel/register

JavaScript
require("@babel/register")({
rootMode: "upward",
});

Webpack

webpack.config.js
module: {
rules: [
{
loader: "babel-loader",
options: {
rootMode: "upward",
},
},
];
}

Jest

Jest 通常安装在大仓的根目录,可能不需要配置,但如果它是按包安装的,那么配置起来可能会更复杂。

¥Jest is often installed at the root of the monorepo and may not require configuration, but if it is installed per-package it can unfortunately be more complex to configure.

主要部分是创建一个自定义的 jest 转换器文件,该文件包含 babel-jest 的默认行为以设置选项,例如

¥The main part is creating a custom jest transformer file that wraps babel-jest's default behavior in order to set the option, e.g.

wrapper.js
module.exports = require("babel-jest").default.createTransformer({
rootMode: "upward",
});

然后将其保存在某处,然后你将通过 转换选项 在你的 Jest 选项中使用该文件代替 babel-jest

¥and with that saved somewhere, you'd then use that file in the place of babel-jest in your Jest options via the transform option:

jest.config.js
"transform": {
"^.+\\.jsx?$": "./path/to/wrapper.js"
},

因此所有 JS 文件都将使用你的 babel-jest 版本处理,并启用该选项。

¥so all JS files will be processed with your version of babel-jest with the option enabled.

注意

当使用 babel-jest < 27 时,必须省略 .default 部分:require("babel-jest").createTransformer({ ...

¥When using babel-jest < 27, you must omit the .default part: require("babel-jest").createTransformer({ ....

其他的

¥Others

有很多工具,但其核心是如果工作目录还不是大仓根目录,它们需要启用 rootMode 选项。

¥There are tons of tools, but at the core of it is that they need the rootMode option enabled if the working directory is not already the monorepo root.

分包 .babelrc.json 个文件

¥Subpackage .babelrc.json files

类似于 babel.config.json 文件必须在 "root" 中的方式,.babelrc.json 文件必须在根包中,默认情况下。这意味着,与工作目录影响 babel.config.json 加载的方式相同,它也会影响 .babelrc.json 加载。

¥Similar to the way babel.config.json files are required to be in the "root", .babelrc.json files must be in the root package, by default. This means that, the same way the working directory affects babel.config.json loading, it also affects .babelrc.json loading.

假设你已经按照上面的讨论正确加载了 babel.config.json 文件,Babel 将只处理该根包(而不是子包)中的 .babelrc.json 文件,例如

¥Assuming you've already gotten your babel.config.json file loaded properly as discussed above, Babel will only process .babelrc.json files inside that root package (and not subpackages), so given for instance

package.json
babel.config.js
packages/
mod/
package.json
.babelrc.json
index.js

编译 packages/mod/index.js 文件不会加载 packages/mod/.babelrc.json,因为这个 .babelrc.json 在子包中,而不是根包中。

¥compiling the packages/mod/index.js file will not load packages/mod/.babelrc.json because this .babelrc.json is within a sub-package, not the root package.

要启用该 .babelrc.json 的处理,你需要使用 babel.config.json 文件中的 "babelrcRoots" 选项来执行

¥To enable processing of that .babelrc.json, you will want to use the "babelrcRoots" option from inside your babel.config.json file to do

JavaScript
babelrcRoots: [
".",
"packages/*",
],

这样 Babel 会认为所有 packages/* 包都允许加载 .babelrc.json 文件,以及原始 repo 根目录。

¥so that Babel will consider all packages/* packages as allowed to load .babelrc.json files, along with the original repo root.

配置函数接口

¥Config Function API

JS 配置文件可能会导出将传递给配置函数 API 的函数:

¥JS config files may export a function that will be passed config function API:

JavaScript
module.exports = function(api) {
return {};
};

api 对象公开了 Babel 本身从其索引模块公开的所有内容,以及配置文件特定的 API:

¥The api object exposes everything Babel itself exposes from its index module, along with config-file specific APIs:

api.version

类型:string

¥Type: string

正在加载配置文件的 Babel 版本的版本字符串。

¥The version string for the Babel version that is loading the config file.

api.cache

JS 配置很棒,因为它们可以即时计算配置,但缺点是它使缓存更难。Babel 希望避免在每次编译文件时重新执行配置函数,因为那样它还需要重新执行该配置中引用的任何插件和预设函数。

¥JS configs are great because they can compute a config on the fly, but the downside there is that it makes caching harder. Babel wants to avoid re-executing the config function every time a file is compiled, because then it would also need to re-execute any plugin and preset functions referenced in that config.

为了避免这种情况,Babel 希望配置函数的用户告诉它如何管理配置文件中的缓存。

¥To avoid this, Babel expects users of config functions to tell it how to manage caching within a config file.

  • api.cache.forever() - Permacache 计算的配置并且永远不会再次调用该函数。

    ¥api.cache.forever() - Permacache the computed config and never call the function again.

  • api.cache.never() - 不要缓存这个配置,每次都重新执行函数。

    ¥api.cache.never() - Do not cache this config, and re-execute the function every time.

  • api.cache.using(() => process.env.NODE_ENV) - 根据 NODE_ENV 的值进行缓存。每当 using 回调返回的值与预期值不同时,将再次调用整体配置函数,并将新条目添加到缓存中。

    ¥api.cache.using(() => process.env.NODE_ENV) - Cache based on the value of NODE_ENV. Any time the using callback returns a value other than the one that was expected, the overall config function will be called again and a new entry will be added to the cache.

  • api.cache.invalidate(() => process.env.NODE_ENV) - 根据 NODE_ENV 的值进行缓存。每当 using 回调返回的值与预期值不同时,将再次调用整个配置函数,并且缓存中的所有条目都将被替换为结果。

    ¥api.cache.invalidate(() => process.env.NODE_ENV) - Cache based on the value of NODE_ENV. Any time the using callback returns a value other than the one that was expected, the overall config function will be called again and all entries in the cache will be replaced with the result.

  • api.cache(true) - 同 api.cache.forever()

    ¥api.cache(true) - Same as api.cache.forever()

  • api.cache(false) - 同 api.cache.never()

    ¥api.cache(false) - Same as api.cache.never()

由于实际回调结果用于检查缓存条目是否有效,因此建议:

¥Since the actual callback result is used to check if the cache entry is valid, it is recommended that:

  • 回调应该很小并且没有副作用。

    ¥Callbacks should be small and side-effect free.

  • 回调应该返回尽可能小的值。例如,上面的 .using(() => process.env.NODE_ENV) 用法并不理想,因为它会根据检测到的 NODE_ENV 值的数量创建未知数量的缓存条目。做 .using(() => process.env.NODE_ENV === "development") 会更安全,因为缓存条目只能是 truefalse

    ¥Callbacks should return values with the smallest range possible. For example, the .using(() => process.env.NODE_ENV) usage above is not ideal because it would create an unknown number of cache entries depending on how many values of NODE_ENV are detected. It would be safer to do .using(() => process.env.NODE_ENV === "development") because then the cache entry can only ever be true or false.

api.env(...)

由于 NODE_ENV 是一种相当常见的切换行为方式,因此 Babel 还包含一个专门用于此的 API 函数。此 API 用作检查 Babel 加载的 "envName" 的快速方法,如果没有设置其他覆盖环境,则将 NODE_ENV 考虑在内。

¥Since NODE_ENV is a fairly common way to toggle behavior, Babel also includes an API function meant specifically for that. This API is used as a quick way to check the "envName" that Babel was loaded with, which takes NODE_ENV into account if no other overriding environment is set.

它有几种不同的形式:

¥It has a few different forms:

  • 如果 envName === "production"api.env("production") 返回 true

    ¥api.env("production") returns true if envName === "production".

  • 如果 ["development", "test"].includes(envName)api.env(["development", "test"]) 返回 true

    ¥api.env(["development", "test"]) returns true if ["development", "test"].includes(envName).

  • api.env() 返回当前的 envName 字符串。

    ¥api.env() returns the current envName string.

  • 如果 env 以 "test-" 开头,则 api.env(envName => envName.startsWith("test-")) 返回 true

    ¥api.env(envName => envName.startsWith("test-")) returns true if the env starts with "test-".

注意

该函数在内部利用上面提到的 api.cache 来确保 Babel 知道该构建依赖于特定的 envName。你不应将其与 api.cache.forever()api.cache.never() 一起使用。

¥This function internally makes use of api.cache mentioned above to ensure that Babel is aware that this build depends on a specific envName. You should not use it alongside with api.cache.forever() or api.cache.never().

api.caller(cb)

此 API 用作访问已传递给 Babel 的 caller 数据的一种方式。由于许多 Babel 实例可能运行在具有不同 caller 值的同一进程中,因此此 API 旨在自动配置 api.cache,与 api.env() 相同。

¥This API is used as a way to access the caller data that has been passed to Babel. Since many instances of Babel may be running in the same process with different caller values, this API is designed to automatically configure api.cache, the same way api.env() does.

caller 值可用作回调函数的第一个参数。它最好与类似的东西一起使用

¥The caller value is available as the first parameter of the callback function. It is best used with something like

JavaScript
function isBabelRegister(caller) {
return !!(caller && caller.name === "@babel/register");
}

module.exports = function(api) {
const isRegister = api.caller(isBabelRegister);

return {
// ...
};
};

根据特定环境切换配置行为。

¥to toggle configuration behavior based on a specific environment.

api.assertVersion(range)

虽然 api.version 通常很有用,但有时只声明你的版本会很好。这个 API 提供了一个简单的方法来做到这一点:

¥While api.version can be useful in general, it's sometimes nice to just declare your version. This API exposes a simple way to do that with:

JavaScript
module.exports = function(api) {
api.assertVersion("^7.2");

return {
// ...
};
};