• We’re releasing the 7.0 Babel release. Here’s all the cool stuff We’ve been doing.
  • Henry Zhu
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: xueshuai
  • Proofread by: Colafornia

Look at this 👋! I’m Henry, one of Babel’s defenders.

Edit: I’ve left Behance and created Patreon to try and focus on open source work full time. Please consider donating to Behance or your company.

Babel profile

Some people might see Babel as a tool that lets you write ES6 code. More specifically, Babel is a JavaScript compiler that converts ES6 code into ES5 code. It worked when it was called 6to5, but I think Babel has become more than that.

Now let’s talk about some background. This is necessary because unlike other languages (even Node.js) running on the server, the version of JavaScript you can run depends on the particular version of your browser. It doesn’t matter if you use the latest browser and your users (whom you want to keep) still use IE. But, for example, if you want to write class A {}, then you’re out of luck – some of your users will get A SyntaxError and A blank page.

So that’s why Babel was created. It allows you to write the version of JavaScript you want, and you know it will work correctly on all the (older) browsers you support.

However, it does not stop with “ES6” (some like to say ES2015). Babel has indeed expanded on its original goal of compiling only ES6 code. Now, it can compile any version of ES20XX (the latest version of JavaScript) you want into ES5.

Ongoing process

One interesting thing about this project is that as soon as the JavaScript syntax is added, Babel needs to implement a converter to convert it.

But why, you might wonder, would we send a compiled version (larger code volume) to a browser that already supports this syntax? How do we know what syntax each browser supports?

Well, we made a tool that lets you specify which browser you support, Babel-Preset -en, to help fix this problem. It will automatically convert only those things that the browser doesn’t support natively.

In addition, Babel (because of its use in the community) could affect the future of the JavaScript language itself. Since it is a tool for transforming JS code, it can also be used to implement any proposal submitted to TC39 (Ecma Technical Committee 39, an organization that moves JavaScript forward as a standard).

A “proposal” enters the language through a complete process from Stage 0 to Stage 4. Babel, as a tool, tests new ideas in the right places and lets developers use it in their applications so they can provide feedback to the committee.

This is important for the following reasons: Committees want to be sure that the changes they make are what the community wants (consistent, intuitive, effective). Implementing an obscure idea in the browser is slow (C++ in the browser versus JavaScript in Babel), expensive, and requires users to use a flag in the browser rather than changing their Babel configuration file.

Because Babel has become so popular, there is a good chance that real use will emerge. This will make the proposal a better implementation than one without feedback from the wider community of developers.

And it’s not just in products. Our online REPL helps people learn JavaScript and allows them to test things.

I think Babel is a great tool for programmers to understand how JavaScript works. By contributing to the project, they will learn many other concepts such as AST, compilers, language specifications, and so on.

We’re really excited about the future of this project and can’t wait to see where this team can go. Please join us and help us!

My story

Here are some reasons why I want to work on this project every day, especially as a maintainer. Most of the current maintainers, myself included, were not the ones who created the project, but joined a year later – it’s still exciting to remember where I started.

As for me, I recognized a need and an interesting project. I slowly and consistently got more involved, and now I’ve been able to get my employer, Behance, to fund half my time working on Babel.

Sometimes “maintenance” just means fixing bugs, answering questions on Slack or Twitter, or writing an update log (it’s really up to each of us). But lately, I’ve been paying less attention to bug fixes and features. Instead, I spent my time thinking about higher-level questions, such as: What is the future of this project? How do we grow our community in terms of the number of maintainers and users. How do we sustain this project financially? How do we integrate into the JavaScript ecosystem as a whole (education, TC39, tools)? Is there a role for us to help new people join open source projects (RGSoC and GSoC)?

Because of these issues, what excites me most about this release is not the features (there are many: Early implementation of the new proposals such as Pipeline Operator (a | b >), with TS team to help new TypeScript preset and the babelrc. Js file).

But I’m more excited in these features represent things: a year unremitting efforts not to break everything, balance the expectations of users (why build so slowly/code input so big, why don’t have enough compatible code, why can’t this job without configuration, why there is no a choice of other cases) and maintain a solid team composed of volunteers.

And I know our industry had a big focus on “major releases”, hyping features and stars, but that was just a fading day. I would suggest that we continue to think about what keeps ecosystems moving forward in a healthy way.

This may simply mean thinking about the psychological and emotional burden on the maintainer. That might mean thinking about how to provide coaching, expectation management, work/life balance advice and other resources that people want to join, rather than just encouraging developers to expect immediate, free help.

Deep update log

Well, I hope you enjoy this long update log 😊. If you are interested in helping us, please let us know and we will be happy to talk more.

Because people want to learn more about how Babel works and gives back, we’ve opened a new video page. This page contains videos of Babel conference talks, concepts from team members and people in the community.

We also created a new team page! We’ll be updating this page in the future with more information about what people are doing and why they’re joining. For a project this big, there are many ways to get involved and help.

Here are some highlights and brief facts:

  • Babel turned 3 years old on October 28, 2017!
  • Daniel leftbabel/babylon 和 babel/babel-preset-env Move to theIn the main Babel Monorepo,babel/babel. This includes Git history, tags, and proposals.
  • We received $1,000 a month in donations from Facebook Open Source!
  • This was the highest monthly donation we’ve received since the beginning (the next one was $100 / month).
  • At the same time, we will use our funds to meet in person and send someone to TC39. These meetings are held every two months around the world.
  • If a company wants to decide what to sponsor, we can create a separate issue to track. This was difficult before because we had to pay for it out of our pockets or find a conference speaker in the same week to help pay for it.

How can you help

If your company is willing to return the favor by supporting a fundamental part of JavaScript development and its future, consider donating to our Open Collective. You can also contribute development time to help maintain the project.

#1: Help maintain the project (developer time at work)

The best thing for Babel is to find people who are willing to help with the project, who can take on a lot of the work and be accountable to the requirements. Again, I never felt ready to be a maintainer, but somehow I found out THAT I was. But I am only one person, and my team is only a few people.

#2: Help fund development

I definitely want to be able to give the people on the team the money to work full time. Logan, in particular, recently left his job and used our funds to work part-time with Babel.

#3 Contribute from other sources

For example, Angus made us an official song!

upgrade

We’ll also update tools to help you rewrite your package.json/.babelrc files and much more. Ideally, this means that it will modify any necessary version number changes, package renames, and configuration changes.

When trying to update, please reach out to help and post issues. This is a great opportunity to get involved and help renew the ecosystem.

Previous releaseconclusion

  • Discontinue support for Node 0.10/0.12/5
  • Update TC39 proposal
  • Number separator:1 _000
  • Optional link operators:a? .b
  • import.meta(Resolvable)
  • Optional Catch binding:try { a } catch {}
  • BigInt (resolvable) :2n
  • Split export extends toexport-default-from 和 export-ns-form
  • support.babelrc.js(Use JavaScript instead of JSON configuration)
  • Add a new Typescript Preset and split React/Flow presets
  • Added JSX staging support and various Flow updates
  • For smaller volume, remove the interiorbabel-runtimeRely on

The latest updated TC39 proposal

  • Pipeline operator:a |> b
  • Throw expression:() => throw 'hi'
  • Invalid merge operator:a ?? b

Deprecating year presets (for example, babel-PRESET – ES20xx)

Note: Use babel-preset-env:

What’s better than you deciding which Babel preset to use? It’s done for you, automatically!

Although maintaining the data list is a lot of work – again, we need help – it solves a lot of problems. It ensures that users are up to date with the specification. It means less configuration/package clutter. It means a simple upgrade path. And it means fewer questions about what is what.

Babel-preset -env is actually a very old preset that replaces every other preset syntax you will need (ES2015, ES2016, ES2017, ES20XX, latest, etc.).

It replaces all the old Presets to compile the latest annual version of JavaScript (whatever it is in Stage 4). But it also has the ability to compile for the target environment you specify: it can handle development modes, such as the latest version of the browser, or multiple builds, such as the Version of Internet Explorer. It even has another version for browsers that have been popular for years

Did not remove Stage presets (babel-preset-stage-x)

We can always update it, and maybe we just need to decide on a better system than the current Presets.

For now, stage Presets are just a list of plug-ins that we manually update after each TC39 meeting. To make this manageable, we need to allow major versions to buffer these “unstable” packages. That’s part of it, because the commission is going to rebuild the bags anyway. So we’ll probably do it from an official package, and then we’ll be able to provide better news and so on.

Renamed: Scoped Packages (@babel/x)

Here’s a poll I posted about a year ago:

Back then, not many projects used scoped packages, so many people didn’t even know they existed. Back then you probably had to pay for an NPM org account, whereas now it’s free (and also supports non-scoped packages).

The problem of searching for Scoped Packages has been resolved and the download count has taken effect. The only stumbling block is that some third-party registrations still do not support Scoped Packages. But I think we are now at a point where it seems unreasonable to wait.

Why we prefer Scoped Packages:

  • Naming difficulties: We don’t need to check if someone else has decided to use our naming conventions on their plug-in
  • We have a similar problem with package squatting
  • Sometimes people createbabel-preset-20xxOr any other bag for fun. We have to post an issue and email it back
  • Someone has a legitimate bag, but it happens to be the same name we want to call it
  • Someone saw that a new proposal was merging (like the optional chaining or pipeline operator), and decided to use the same name for fork and publish. Then, when we publish, we are told that the package has been published 🤔. So I had to find emails from both them and the NPM support team, bring the package back and republish it.
  • What is an “official” package and what is a user/community package under the same name? We’ve had reports of people using the wrong name or unofficial package because they thought it was part of Babel. One example of this is a report that saysbabel-envRewrote theirs.babelrcFile. It took them a while to realize it wasn’tbabel-preset-env.

So, it’s clear that we should use scoped packages and, whatever, we should get it done faster!

Examples of scoped name changes:

  • babel-cli -> @babel/cli
  • babel-core -> @babel/core
  • babel-preset-env -> @babel/preset-env

Rename:-proposal-

Now any proposals will be marked with the -proposal-name as they are not yet in JavaScript official.

So @babel/plugin-transform-class-properties becomes @babel/plugin-proposal-class-properties, and when it goes to Stage 4, we’ll name it back.

Rename: Remove the year from the plugin name

Plugins used to have a year in their names, but that doesn’t seem to be a requirement now.

So @babel/plugin-transform-es2015-classes becomes @babel/plugin-transform-classes.

Since the year is only for ES3 / ES2015, we haven’t changed anything from ES2016 or ES2017. Anyway, we set those presets to preset-env, and for the literal template adjustment, we simply add it to the literal template transformation.

Peer dependencies and integrations

< span style = “box-sizing: border-box; word-wrap: inherit! Important;” Presets (@babel/preset-env) and Top level packages (@babel/cli, babel-loader)

PeerDependencies are dependencies that are expected to be used by your code, as opposed to dependencies that are only used for implementation details. – Answer by Stijn De Witt on StackOverflow

Babel-loader already has a peerDependency on babel-core, so this just changes it to @babel/core. This change prevents people from trying to install the wrong version of these Babel packages.

For tools that already have peerDependency in Babel-core and are not ready for a major update (because changing peerDependency is a breaking change), We have released a new version of Babel-Core to bridge the changes on the new version [email protected]. For more information, check out this topic.

Similarly, packages like gulp-babel, rollup-plugin-babel, and so on used babel-core as a dependency. Now, these will only have peerDependency on @babel/core. Because of this, there is no need for these packages to upgrade to major versions when the @babel/core API changes

# 5224: Independently release experimental packages

I mentioned this in the Versioning section of Babel’s state. This is Github Issue.

You may remember that after Babel 6, Babel became a set of NPM packages with its own ecosystem, with custom Presets and plugins.

However, since then, we have been using a “fixed/synchronized” version system (so no packages are v7.0 or above). When we make a new release, such as V6.23.0, only packages with updated source code are released with the new release. The rest of the bags were left as they were. This mostly works in practice because we use ^ in our packages.

Unfortunately, when a package needs a major release, such a system needs to release one for all packages. This either means we make a lot of small breaking changes (unnecessary), or it means we pack a lot of breaking changes into a release. Instead, we want to distinguish experimental packages (Stage 0, etc.) from all others (ES2015).

Because of this, when the specification changes, we intend to iterate over the main version of all experimental proposal plugins, not just wait to update all Babel. So anything prior to Stage 4 will be open to Breaking Changes in the form of a major release iteration. The Stage presets themselves are the same (if we don’t throw them away altogether).

Along with this came our decision to call TC39 proposal to use the name -proposal-, and we will do a major release iteration of the plugin and its preset (instead of just a potentially disappointing preset patch). Then, we’ll need to discard the old version and build a framework that will update automatically no matter what the specification becomes to keep people up to date (and keep them from getting stuck on anything). We are not as lucky as decorators. .

.babelrcIn theenvThe options are still in use

Unlike the last commit, we just fixed the merged behavior to make it more compatible

The configuration in env is given priority over the root configuration item. And now merge according to their identity, instead of just using the strange implementation of plugins and Presets at the same time, we can now do this:

{  presets: [    ['env', { modules: false}],  ],  env: {    test: {      presets: [         'env',}}}Copy the code

With BABEL_ENV=test, it replaces the root environment configuration with the configuration in test without options.

support[class A extends Array](https://twitter.com/left_pad/status/940723982638157829)(The earliest warning)

Babel will automatically contain native built-in elements like Array, Error, and HTMLElement, so this will work when classes are compiled.

speed

  • Lots of fixes from V8 team Bmeurer!
  • Through the web – tooling – benchmark twitter.com/left_pad/st… To speed up 60%

Preset – env:"UseBuiltins" : "usage"

Babel-preset -env introduces the idea of compiling syntax to different targets. It also introduces the ability to add unsupported polyfills only to the target with the useBuiltIns option.

So with this option, something like:

import "babel-polyfill";
Copy the code

Can become

import "core-js/modules/es7.string.pad-start"; import"core-js/modules/es7.string.pad-end"; / /...Copy the code

If the target environment happens to support polyfills other than padStart or padEnd.

But to make it better, we should just introduce polyfills that the code base itself “uses.” If it doesn’t use padStart in the code, why introduce it?

“UseBuiltins “:” Usage “was our first attempt to tackle that idea. It performs an import at the head of each file, but adds a reference only if it is found to be used in the code. This implementation means that we can introduce the minimum amount of necessary polyfills for the application (and only if the target environment does not support it).

So if you use Promise in your code, it will introduce it in the header of your file (if your target doesn’t support it). If it is duplicate, Bundlers will remove the duplicate parts, so the implementation will not cause multiple references to polyfills.

import "core-js/modules/es6.promise"; var a = new Promise();Copy the code
import "core-js/modules/es7.array.includes"; [].includesa.includesCopy the code

Type inference tells us if an instance like.includes is an array. Until the logic gets better, it’s ok to get a false positive because it’s still better than introducing the whole polyfill before.

Other updates

  • [babel-template](https://github.com/babel/babel/blob/master/packages/babel-template)Faster and easier to use
  • Regenerator is released under the MIT certificate – it is used to compile generators/async dependencies
  • through# 6952 的 modules-commonjsPlugin’s “lazy” option
  • You can now use it in.babelrcenvName: "something"Or enter it from the command linebabel --envName=somethingInstead of having to useprocess.env.BABEL_ENV 或 process.env.NODE_ENV
  • ["transform-for-of", { "assumeArray": true }]Make all for-of loops output as a regular array
  • In order to preset – env# 6831In loose modetransform-typeof-symbol
  • Implement PR to get better syntax error messages

Need to do before release

  • Handle [.babelrc](https://github.com/babel/babel/issues/6766) lookup(Want to finish before the first RC release)
  • Overrides support: differential configuration based on the global mode
  • Caching and invalid logic in babel-core
  • A better story around external helpers.
  • For iterating and handling independently of helpers there’s either a mature plan to implement it or implement it, so we’re not explicitly tied to Core-JS 2 or 3. People may have things that depend on one or the other, and don’t want to load too much of both.
  • Whether it is an implementation of working Decorator or functional Legacy, there is a clear path to implement the behavior of the current standard during the 7.x’s lifetime.

Thank you

To our team of volunteers:

Logan has worked hard to fix a lot of our core issues with configuration and more. He is the man who has done all the difficult work.

Brian has taken over a lot of maintenance of preset-env, whatever I’ve done before 😛

Daniel has been stepping in whenever we need help, whether it’s maintaining babel-Loader or helping to migrate the Babylon/babel-Preset -env library. Also, Nicolo, Sven, Artem and Diogo helped do more last year.

I’m really looking forward to a release (I’m tired too – it’s been almost a year 😝). But I don’t want to rush anything, because there’s been a lot of ups and downs in this version. I did learn a lot, and I’m sure the rest of the team did too.

If I learned anything this year, I should have actually followed that advice instead of just writing it down.

Thanks also to Mariko for the nudging that actually made this release (two months in the making).

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.