7.13.0 Released: Records and Tuples, granular compiler assumptions, and top-level targets
We just published Babel 7.13.0, the first minor release of 2021!
This release includes some important features to @babel/core
: a targets
option (similar to @babel/preset-env
's one) that can be shared across different plugins, an assumptions
option to precisely tune your configuration to produce a smaller compilation output, and support for plugins and presets written using native ECMAScript modules.
Babel now supports transforming the Records and Tuples ECMAScript proposal, which brings immutable data structures and structural equality to JavaScript, and parsing the Module Blocks proposal.
Additionally, we added support for some new Flow and TypeScript features.
You can read the full changelog on GitHub.
Funding Update
We have joined the "GitHub Sponsors for organizations" program, so you can now sponsor us directly through GitHub 😊.
These funds are used to support our team's (currently one full-time and three part-time maintainers) continued efforts in improving stability and developing new features.
Both our donations and expenses are openly tracked through our Open Collective page, where we will also track donations coming from GitHub Sponsors.
We welcome donations from both individual and companies. If your company is interested in becoming a Gold tier sponsor ($1k/month) and wants to discuss more, please reach out to team@babeljs.io!
Highlights
Top-level targets
option (#12189, RFC)
@babel/preset-env
's targets
option allows users to specify their target environments, automatically choosing which syntax to transform and what polyfills to inject. Since releasing @babel/preset-env
, we've learned that plugins themselves can also benefit from knowing your targets. Currently, this can a bit cumbersome, as you have to specify your targets twice (for example, if you are using our new polyfill plugins). By introducing targets
as a top level option, you now only have to specify your targets once:
Old configuration | New configuration |
---|---|
babel.config.json
| JSON
|
We recommended converting your Babel config to use the new top-level targets
option, as it has the following additional benefits:
- It has better handling of the
esmodules: true
target. (it's intersected with the other targets, rather than replacing them) - As we introduce additional
targets
-related support in our plugins, you'll automatically benefit from more optimized output!
You can read the details about this new option in its RFC.
🔮 In the future we might explore moving
@babel/preset-env
into@babel/core
so that you don't have to install an additional package to get started with Babel. This new option can be seen as the first step in that direction!
Top-level assumptions
option (#12219, RFC)
Many of our plugins have a loose
option, which tells Babel to generate smaller/faster output by making certain assumptions about your code and ignoring certain edge cases in the JavaScript spec.
However, loose
has some problems that lead to user confusion: the term itself does not help to describe how exactly it affects the compiler's behavior and, worse, sometimes requires setting configuration for multiple plugins to ensure everything compiles.
To help fix these problems, we've added a new top level option to tell Babel which assumptions it can make about your code: assumptions
! Similar to the new targets
option, every plugin will now receive the assumptions you've enabled, eliminating the need to set the option individually. This is really valuable since a plugin can be influenced by multiple assumptions, and an assumption can influence multiple plugins.
This is advanced functionality. Like the previous loose
option, please be careful when enabling assumptions, because they are not spec-compliant and may break your code in unexpected ways.
For example, when transforming classes, Babel will generate this output by default:
Input | Output |
---|---|
JavaScript
| JavaScript
|
However, enabling the noClassCalls
assumption tells Babel "I'm never trying to call classes without new
, so you can compile without worrying about it":
{
"targets": "firefox 30",
"assumptions": { "noClassCalls": true },
"presets": ["@babel/preset-env"]
}
Input | Output |
---|---|
JavaScript
| JavaScript
|
Check out the full list of assumptions over in our documentation, where you can individually enable or disable them to see how they affect the compiled output.
Records and Tuples support (#12145)
Thanks to a collaboration with Bloomberg, Babel now supports transforming the "Records and Tuples" stage 2 proposal.
The Babel plugin transforms records and tuples syntax using the global Record
and Tuple
functions:
Input | Output |
---|---|
JavaScript
| JavaScript
|
This means that you will need to load a polyfill for those global functions, such as @bloomberg/record-tuple-polyfill
, either by importing it in your code or with a <script>
tag:
<script src="https://unpkg.com/@bloomberg/record-tuple-polyfill@0.0.3/lib/index.umd.js" />
NOTE: No engine currently supports records and tuples, so you always need to load the polyfill.
In order to enable this transform, you need to add @babel/plugin-proposal-record-and-tuple
to your configuration.
New Flow features (#12193, #12234)
Babel 7.13.0 has support for two new Flow features:
-
this
type annotation in functions, that allow you to specify the type of thethis
object as if it was a parameterJavaScriptfunction getPerson(this: Database, id: string): Person {
this instanceof Database; // true
} -
enum
declarations with unknown membersJavaScriptenum PetKind {
Dog,
Cat,
Snake,
...
}
TypeScript 4.2 support (#12628)
TypeScript 4.2 supports some new syntax features such as abstract constructor signatures.
You can read more about the changes in the TypeScript release post.
Automatic ES modules in @babel/runtime
(#12632)
@babel/runtime
contains all of the Babel runtime helpers in both CommonJS and ECMAScript module formats.
Until now, you had to manually choose which one you wanted to use, specifying the useESModules
option of @babel/plugin-transform-runtime
.
We have now reorganized @babel/runtime
's internal structure, leveraging the new "exports"
package.json
field supported by Node.js and bundlers, so that they are able to automatically choose between CJS and ESM.
For this reason, the useESModules
option is now deprecated and will be removed in Babel 8.