Node.js is one of the most popular back-end technologies out there right now. It is friendly, robust, and well-maintained and it's not going anywhere anytime soon.

To help you learn how to use it effectively, in this article we will create a simple server using Node with Babel configured in our code.

But before we take a deep dive into building out our server, let's learn more about what Babel is.

What is Babel?

Babel is a JavaScript compiler. It's a popular tool that helps you use the newest features of the JavaScript programming language.

Why use Babel in Node.js?

Have you ever opened a back end repo built with Node.js/Express – and the very first thing you saw was the ES6 import and export statements along with some other cool ES6 syntax features?

Well, Babel made all that possible. Remember that Babel is a popular tool that lets you use the newest features of JavaScript. And many frameworks today use Babel under the hood to compile their code.

For example, Node can't use ES6 import and export statements and some other cool features of ES6 syntax without the help of a compiler like Babel.

So in this tutorial, I'll show you how to quickly setup your Node app to be compatible with most ES6 syntax.

Awesome right? Let's dive in.

Prerequisites

This tutorial assumes that that you have the following:

• Basic knowledge of Node.js
• Node installed on your machine
• Any code or text editor of your choice

Getting Started

Let's setup a basic Node app which we will use for this tutorial.

Create a new folder. For this tutorial, I'll call mine node-babel. Now add the folder to the workspace, and open your terminal.

Let's initialize and create a package.json file for our app:

npm init

This command will show some setup steps which we want to leave as it is. So hitting the enter or return key throughout the setup will work fine.

Now once you're done, create a new file called "index.js" which will serve as our entry point.

How to Set Up And Install Babel

Now, we will install three packages from the Babel family which are:

@babel/cli, @babel/core and @babel/preset-env

To install, we use the command below to install the package:

npm install --save-dev @babel/cli @babel/core @babel/preset-env

We want to use the --save-dev to install them as dependencies for the development of your module.

So once you're done with the installation, create a new file called .babelrc for configuring babel.

touch .babelrc

This file will host all of the options we want to add to Babel. So for now, let's use the setup which I normally use for development in my app. You can copy it and add to yours:

{
  "presets": [
    ["@babel/env", {
      "targets": {
        "node": "current"
      }
    }]
  ],
  "plugins": [
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"
  ]
}

The configuration above is what I use to tell Babel that yes, I want to use not only my import and export statements but also the class feature as well as the rest and spread operators from ES6.

Awesome yeah? Let's move on.

How to Set Up A Simple Server

Now open up the "index.js" file we created earlier, and add this code to generate a simple server:

import http from 'http';

const server = http.createServer((req, res) => {
  res.end('Hello from the server');
}).listen(4001);

console.log('Server is up and running');

export default server;

With the sample code above our server will listen on port 4001 and then send a "Hello from the server" response to us whenever we visit the port.

Package.json Script Configurations.

We now have a simple server. To run this, we have to transpile our code before running with Node. To do this, open the "package.json" file and add this build and start script:

  "scripts": {
+   "build": "babel index.js -d dist",
    "start": "npm run build && node dist/index.js"
  }

Nice – so let's start our server with this command:

npm start

You should get this response once you visit localhost:4001

How to Use Nodemon to Watch and Restart Your Server

To prevent restarting the server yourself whenever you make changes to your app, we need to install nodemon. You can install nodemon to your application using this command to install it as a dev dependency:

npm install --save-dev nodemon

And then we reconfigure our package.json scripts:

  "scripts": {
    "build": "babel index.js -d dist",
    "start": "npm run build && nodemon dist/index.js"
  }

Awesome, now this is the final code of our Node app and what you should get when you run "npm start" to start up your server.

As you can see from the image above, our server is up and running. You can now make use of the import and export statement from the es6 syntax and other awesome features es6 provides like the rest and spread operators in your Node application.

Conclusion

In this tutorial, we've learned how to use the awesome ES6 syntax in our Node app using Babel.

Note that you can add more configurations in your .babelrc file. It is not limited to what we have in this tutorial – so feel free to tweak or change it.

You can find the sample code here: https://github.com/Veri5ied/node-babel

Happy Hacking!

If you are just getting started with JavaScript, the number of tools and technologies you'll hear about may be overwhelming. And you might have a hard time deciding which tools you actually need.

Or maybe you're familiar with the tools, but you haven't given much thought to what problems they solve and how miserable your life would be without their help.

I believe it is important for Software Engineers and Developers to understand the purpose of the tools we use every day.

That's why, in this article, I look at NPM, Babel, Webpack, ESLint, and CircleCI and I try to clarify the problems they solve and how they solve them.

NPM

NPM is the default package manager for JavaScript development. It helps you find and install packages (programs) that you can use in your programs.

You can add npm to a project simply by using the "npm init" command. When you run this command it creates a "package.json" file in the current directory. This is the file where your dependencies are listed, and npm views it as the ID card of the project.

You can add a dependency with the "npm install (package_name)" command.

When you run this command, npm goes to the remote registry and checks if there is a package identified by this package name. If it finds it, a new dependency entry is added to your package.json and the package, with it's internal dependencies, is downloaded from the registry.

You can find downloaded packages or dependencies under the "node_modules" folder. Just keep in mind that it usually gets pretty big – so make sure to add it to .gitignore.

NPM does not only ease the process of finding and downloading packages but also makes it easier to work collaboratively on a project.

Without NPM, it would be hard to manage external dependencies. You would need to download the correct versions of every dependency by hand when you join an existing project. And that would be a real hassle.

With the help of npm, you can just run "npm install" and it will install all external dependencies for you. Then you can just run it again anytime someone on your team adds a new one.

Babel

Babel is a JavaScript compiler or transpiler which translates the ECMAScript 2015+ code into code that can be understood by older JavaScript engines.

Babel is the most popular Javascript compiler, and frameworks like Vue and React use it by default. That said, concepts we will talk about here are not only related to Babel and will apply to any JavaScript compiler.

Why do you need a compiler?

"Why do we need a compiler, isn't JavaScript an interpreted language?" you may ask if you are familiar with the concepts of compiled and interpreted languages.

It's true that we usually call something a "compiler" if it translates our human-readable code to an executable binary that can be understood by the CPU. But that is not the case here.

The term transpiler may be more appropriate since it is a subset of a compiler: Transpilers are compilers that translate the code from a programming language to another language (in this example, from modern JS to an older version).

JavaScript is the language of browsers. But there is a problem with browsers: Cross compatibility. JavaScript tools and the language itself are evolving rapidly and many browsers fail to match that pace. This results in compatibility issues.

You probably want to write code in the most recent versions of JavaScript so you can use its new features. But if the browser that your code is running has not implemented some of the new features in its JavaScript engine, the code will not execute properly on that browser.

This is a complex problem because every browser implements the features at a different speed. And even if they do implement those new features, there will always be people who use an older version of their browser.

So what if you want to be able to use the recent features but also want your users to view those pages without any problems?

Before Babel, we used polyfills to run older versions of certain code if the browser did not support the modern features. And when you use Babel, it uses polyfills behind the scenes and does not require you to do anything.

How do transpilers/compilers work?

Babel works similar to other compilers. It has parsing, transformation, and code generation stages.

We won't go in-depth here into how it works, since compilers are complicated things. But to understand the basics of how compilers work, you can check out the the-super-tiny-compiler project. It is also mentioned in Babel's official documentation as being helpful in understanding how Babel works.

We can usually get away with knowing about Babel plugins and presets. Plugins are the snippets that Babel uses behind the scenes to compile your code to older versions of JavaScript. You can think of each modern feature as a plugin. You can go to this link to check out the full list of plugins.

List of plugins for ES5

Presets are collections of plugins. If you want to use Babel for a React project you can use the pre-made @babel/preset-react which contains the necessary plugins.

React Preset Plugins

You can add plugins by editing the Babel config file.

Do you need Babel for your React App?

For React, you need a compiler because React code generally uses JSX and JSX needs to be compiled. Also the library is built on the concept of using ES6 syntax.

Luckily, when you create a project with create-react-app, it comes with Babel already configured and you usually do not need to modify the config.

Examples of a compiler in action

Babel's website has an online compiler and it is really helpful to understand how it works. Just plug in some code and analyze the output.

Webpack

Webpack is a static module bundler. When you create a new project, most JavaScript frameworks/libraries use it out of the box nowadays.

If the phrase "static module bundler" sounds confusing, keep reading because I have some great examples to help you understand.

Why do you need a bundler?

In web apps you're going to have a lot of files. This is especially the case for Single Page Applications (React, Vue, Angular), with each having their own dependencies.

What I mean by a dependency is an import statement – if file A needs to import file B to run properly, then we say A depends on B.

In small projects, you can handle the module dependencies with <script> tags. But when the project gets larger, the dependencies rapidly become hard to manage.

Maybe, more importantly, dividing the code into multiple files makes your website load more slowly. This is because the browser needs to send more requests compared to one large file, and your website starts to consume a ton of bandwidth, because of HTTP headers.

We, as developers want our code to be modular. We divide it into multiple files because we do not want to work with one file with thousands of lines. Still, we also want our websites to be performant, to use less bandwidth, and to load fast.

So now, we'll see how Webpack solves this issue.

How Webpack works

When we were talking about Babel, we mentioned that JavaScript code needs to be transpiled before the deployment.

But compiling with Babel is not the only operation you need before deploying your project.

You usually need to uglify it, transpile it, compile the SASS or SCSS to CSS if you are using any preprocessors, compile the TypeScript if you are using it...and as you can see, this list can get long easily.

You do not want to deal with all those commands and operations before every deployment. It would be great if there was a tool that did all that for you in the correct order and correct way.

The good news – there is: Webpack.

Webpack also provides features like a local server with hot reload (they call it hot module replacement) to make your development experience better.

So what's hot reloading? It means that whenever you save your code, it gets compiled and deployed to the local HTTP server running on your machine. And whenever a file changes, it sends a message to your browser so you do not even need to refresh the page.

If you have ever used "npm run serve", "npm start" or "npm run dev", those commands also start Webpack's dev server behind the scenes.

Webpack starts from the entry point of your project (index) and generates the Abstract Syntax Tree of the file. You can think of it as parsing the code. This operation is also done in compilers, which then look for import statements recursively to generate a graph of dependencies.

It then converts the files into [IIFEs](https://developer.mozilla.org/en-US/docs/Glossary/IIFE#:~:text=An%20IIFE%20(Immediately%20Invoked%20Function,soon%20as%20it%20is%20defined.) to modularize them (remember, putting code inside a function restricts its scope). By doing this, they modularize the files and make sure the variables and functions are not accessible to other files.

Without this operation, it would be like copying and pasting the code of the imported file and that file would have the same scope.

Webpack does many other advanced things behind the scenes, but this is enough to understand the basics.

Bonus – ESLint

Code quality is important and helps keep your projects maintainable and easily extendable. While most of us developers recognize the significance of clean coding, we sometimes tend to ignore the long term consequences under the pressure of deadlines.

Many companies decide on coding standards and encourage developers to obey those standards. But how can you make sure that your code meets the standards?

Well, you can use a tool like ESLint to enforce rules in the code. For example, you can create a rule to enforce or disallow the usage of semicolons in your JavaScript code. If you break a rule, ESLint shows an error and the code does not even get compiled – so it is not possible to ignore that unless you disable the rule.

Linters can be used to enforce standards by writing custom rules. But you can also use the pre-made ESLint configs established by big tech companies to help devs get into the habit of writing clean code.

You can take a look at Google's ESLint config here – it is the one I prefer.

ESLint helps you get used to best practices, but that's not its only benefit. ESLint also warns you about possible bugs/errors in your code so you can avoid common mistakes.

Bonus – CI/CD (CircleCI)

Continuous Integration/Development has gained a lot of popularity in recent years as many companies have adopted Agile principles.

Tools like Jenkins and CircleCI allow you to automate the deployment and testing of your software so you can deploy more often and reliably without going through difficult and error-prone build processes by yourselves.

I mention CircleCI as the product here because it is free and used frequently in JavaScript projects. It's also quite easy to use.

Let's go over an example: Say you have a deployment/QA server and your Git repository. You want to deploy your changes to your deployment/QA server, so here is an example process:

1. Push the changes to Git
2. Connect to the server
3. Create a Docker container and run it
4. Pull the changes to the server, download all the dependencies (npm install)
5. Run the tests to make sure nothing is broken
6. Use a tool like ESLint/Sonar to ensure code quality
7. Merge the code if everything is fine

With the help of CircleCI, you can automatically do all these operations. You can set it up and configure to do all of the above operations whenever you push a change to Git. It will reject the push if anything goes wrong, for example a failing test.

I will not get into the details of how to configure CircleCI because this article is more about the "Why?" of each tool. But if you are interested in learning more and seeing it in action, you can check out this tutorial series.

Conclusion

The world of JavaScript is evolving rapidly and new tools are gaining popularity every year.

It's easy to react to this change by just learning how to use the tool – we are often too busy to take our time and think about the reason why that tool became popular or what problem it solves.

In this article, I picked the tools I think are most popular and shared my thoughts on their significance. I also wanted to make you think about the problems they solve rather than just the details of how to use them.

If you liked the article you can check out and subscribe to my blog where I try to write frequently. Also, let me know what you think by commenting so we can brainstorm or you can tell me what other tools you love to use :)

Optional chaining, represented by ?. in JavaScript, is a new feature introduced in ES2020.

Optional chaining changes the way properties are accessed from deeply nested objects. It fixes the problem of having to do multiple null checks when accessing a long chain of object properties in JavaScript.

Current Status: ECMAScript proposal at stage 4 of the process. : https://github.com/tc39/proposal-optional-chaining

Use cases

1. Accessing potentially null or undefined properties of an object.
2. Getting results from a variable that may not be available yet.
3. Getting default values.
4. Accessing long chains of properties.

Imagine you are expecting an API to return an object of this sort:

obj = {
  prop1: {
    prop2: {
      someProp: "value"
    }
  }
};

But you may not know if each of these fields are available ahead of time. Some of them may not have been sent back by the API, or they may have come back with null values.

Here is an example:

//expected
obj = {
  id: 9216,
  children: [
    { id: 123, children: null },
    { id: 124, children: [{ id: 1233, children: null }] }
  ]
};

//actual
obj = {
  id: 9216,
  children: null
};

This happens very often with functions that call APIs. You may have seen code in React that tries to safeguard against these issues like this:

render = () => {
  const obj = {
    prop1: {
      prop2: {
        someProp: "value",
      },
    },
  };

  return (
    <div>
      {obj && obj.prop1 && obj.prop1.prop2 && obj.prop1.prop2.someProp && (
        <div>{obj.prop1.prop2.someProp}</div>
      )}
    </div>
  );
};

In order to better prepare for this issue, often times in the past we have used Lodash, specifically the _.get method:

_.get(obj, prop1.prop2.someProp);

This outputs undefined if either of those properties are undefined. Optional chaining is exactly that! Now instead of using an external library, this functionality is built-in.

How does optional chaining work?

?. can be used to chain properties that may be null or undefined.

const propNeeded = obj?.prop1?.prop2?.someProp;

If either of those chained properties is null or undefined, JavaScript will return undefined.

What if we want to return something meaningful? Try this:

let familyTree = {
    us: {
        children: {}
    }
}


// with _.get
const grandChildren = _.get(familyTree, 'us.children.theirChildren', 'got no kids' );

//with optional chaining and null coalescing 
const nullCoalescing = familyTree?.us?.children?.theirChildren ?? 'got no kids'
console.log(nullCoalescing) //got no kids

It also works for objects that may be null or undefined:

let user;
console.log(user?.id) // undefined

How to get this newest feature

1. Try it in your browser's console: This is a recent addition and old browsers may need polyfills. You can try it in Chrome or Firefox in the browser's console. If it doesn't work, try turning on JavaScript experimental features by visiting chrome://flags/ and enabling "Experimental JavaScript".

2. Try it in your Node app by using Babel:

   {
   "plugins": ["@babel/plugin-proposal-optional-chaining"]
   }
   

Resources

1. https://dmitripavlutin.com/javascript-optional-chaining/
2. Babel's doc: https://babeljs.io/docs/en/babel-plugin-proposal-optional-chaining

TL;DR

Use optional chaining ?. for objects or long chain properties that may be null or undefined. The syntax is as follows:

let user = {};
console.log(user?.id?.name)

Interested in more tutorials and JSBytes from me? Sign up for my newsletter. or follow me on Twitter

Moving forward with v7, we’ve decided it’s best to stop publishing the Stage presets in Babel (for example,@babel/preset-stage-0).

We didn’t make this decision lightly, and wanted to show the context behind the interplay between TC39, Babel, and the community.

Some History

A Babel preset is a shareable list of plugins.

The official Babel Stage presets tracked the TC39 Staging process for new syntax proposals in JavaScript.

Each preset (ex. stage-3, stage-2, and so on) included all the plugins for that particular stage and the ones above it. For example, stage-2 included stage-3, and so on.

This allowed users who wanted to use experimental syntax to simply add the preset, instead of needing to configure/install each individual plugin.

We actually added the Stage presets shortly after Babel’s v6 release (it was previously a config flag in v5). Shown below is an older example.

Problems

These presets were a convenient way to use what we all wanted: the new, shiny, “yet-to-be-determined” future of JavaScript.

Looking back, it worked really well! (Maybe too well?)

Too Good a Job?

Languages like CoffeeScript and tooling like Traceur helped establish the idea of compiling JavaScript. Babel made it even easier to both use new/future syntax and integrate with existing tooling. The expectations changed from skepticism and worry to completely embracing the experimental.

We probably wouldn’t be where we are if not for the wide adoption of compilers such as Babel: it accelerated the usage (and teaching) of ES2015 to a much larger audience. The growth of React further fueled usage, as its JSX syntax, class properties, and object rest/spread led to people knowing a bit more about these syntax proposals.

Babel became a one-time setup for people, never to be thought of again. It became the underlying infrastructure, hidden behind other tools until there was a SyntaxError, dependency issues, or integration issues. Simply use stage-0.

This was awesome to see in some ways, as it meant that these ideas were being tested in the wild, even in production environments. However, it also meant that many companies, tools, and people would encounter some trouble if a proposal changed in a significant way (or even got dropped altogether).

Back and Forth

Over the years, we’ve raised many issues to discuss what to do with the Stage presets in #4914, #4955, #7770. I even wrote in an older post about Babel 7.0 that said we weren’t removing them ?.

However, we found that keeping the Stage presets would lead to issues even for Babel itself:

• It was a common issue to ask something like: “What presets(s) are needed to use async functions?” It would be unclear for people to know exactly what stage-0 meant, and few people would look at its package.json or source.
• Removing a proposal plugin in Stage 3 (once it moves to Stage 4) is actually a breaking change. This issue is exacerbated when you are trying to use @babel/preset-env to not compile a natively supported proposal.

“ES7 Decorators”

Part of the issue is precisely around naming things, and as we often hear, naming things is hard.

There were a lot of names for ES6 itself: Harmony, ES Next, ES6, ES2015. When people hear about new ideas, it makes sense to just pick the latest number and attach the name to it.

It’s completely understandable that this happens without realizing it, but continuing to do so sets different expectations for how the language progresses. It’s nothing to feel guilty about — we learn as a community and remind one another of how JavaScript works.

Jay Phelps wrote a nice article about this subject. He explains it would be best to call them by the “Stage” they are currently at: “Stage 2 Decorators”, or just simply the “Decorators Proposal”.

The reasoning is that saying “ES7 Decorators” assumes that Decorators is expected to be in ES7. I mentioned this in my last post regarding compiling node_modules, but being in a particular Stage doesn’t guarantee much: a proposal can stall, move backward, or get removed entirely.

We wanted to highlight this fact when we decided to change the names of the proposal plugins from @babel/plugin-transform- to @babel/plugin-proposal-.

BabelScript

Having presets for proposals so early in the process may imply that these proposals are guaranteed to move forward or have a stable implementation.

TC39 urges caution when using Stage 2-or below proposals, as it might result in inadvertent pressure from the community to keep the implementation as-is instead of improving it for fear of breaking existing code or ecosystem fragmentation (for example, using a different symbol like # instead of @ for decorators).

People joke that developers who use Babel are using “BabelScript” instead of JavaScript, implying that somehow once a Babel plugin is made for a certain feature, that must mean it’s “fixed” or officially part of the language already (which is not true). For some, the first thought for people when they see a new syntax/idea (Stage “-1”) is whether there is a Babel plugin for it.

Setting Expectations

After compilers like Babel made it common practice for people to write ES2015, it was natural for developers to want to try out even newer and more experimental “features”. The way this worked in Babel was to use the stage flag in previous versions or the stage-x presets.

Being the most convenient way of opting into any new feature, it quickly became the default for people when configuring Babel (even though in Babel v6 it moved to not doing anything by default, which caused lots of complaints).

There were a lot of good discussions even years ago, but it wasn’t the easiest thing to navigate: we wouldn’t want to penalize users who understood the tradeoffs by putting console.warns when using it, and not having the option at all seemed unreasonable at the time.

Blindly opting into Stage 0 (whether we had it by default) or people choosing to do so seems dangerous, but also never using any proposals is overly cautious. Ideally, everyone should able to make an informed decision about the kinds of features that seem reasonable to them and use them wisely, regardless of what stage they are in. Mike Pennisi wrote a great post about these concerns.

It isn’t our intention to threaten, rush, or force specific things into the ecosystem or JavaScript but to faithfully maintain the implementation/discussions around new ideas.

Other Considerations

We also could have tried to:

• Rename the presets to better signify the stability level (doesn’t solve the versioning problem)
• Better versioning strategies: independently version the presets and update them immediately when needed, maybe use 0.x
• Warn/Error for old out-of-date versions of presets

In the end, people would still have to look up what proposals are at what Stage to know which ones to use if we kept the Stages in.

Why Now?

Why not remove it earlier? The Stage presets have been part of Babel for years, and there were concerns with adding more “complexity” to using Babel. A lot of tooling, documentation, articles, and knowledge were built around the Stage presets. Earlier, we thought it was better to officially maintain the presets since someone else would (and will) inevitably create them.

We’re trying to determine the right level of feedback: if it’s only the committee that decides what goes into the language, it may lead to well-specified features that are not needed. But if the community expects that in-progress, experimental proposals are considered stable or ok to use in production without consequence, then we’ll have other issues. We all want to move forward and proceed with intention: not rushing, but not being too cautious. Babel is the right place to do that experimentation, but knowing where the boundaries are is necessary.

Removing the presets would be considered a “feature,” since it means someone would have to make an explicit decision to use each proposal. This is reasonable for any proposal, since they all have varying levels of instability, usefulness, and complexity.

We fully expect some initial backlash from this, but ultimately feel that removing the Stage presets is a better decision for us all in the long run. However, removing previous defaults or removing the Stage presets doesn’t mean we don’t care about ease of use, new users, or documentation. We work with what we can to keep the project stable, provide tooling to make things better, and document what we know.

Migrating

For a more automatic migration, we have updated babel-upgrade to do this for you (you can run npx babel-upgrade).

The TL;DR is that we’re removing the Stage presets. At some level, people will have to opt-in and know what kinds of proposals are being used instead of assuming what people should use, especially given the unstable nature of some of these proposals. If you use another preset or a toolchain, (e.g. create-react-app) it’s possible that this change doesn’t affect you directly.

We have deprecated the Stage presets as of 7.0.0-beta.52. If you don't want to change your config now, we would suggest you pin the versions to beta.54 until you can upgrade. After beta.54 we will throw an error with a message saying how to migrate. And check that all your versions are the same while in prerelease.

As an alternative, you are free to make your own preset that contains the same plugins and upgrade them as you please. In the future, we may want to work on a babel-init that can help you set up plugins interactively or update babel-upgrade itself to list and add the current Stage plugins. Maybe Babel should stay a low-level tool and rely on other higher-level/framework tools like create-react-app to handle these choices for people.

Preventing Proposal Lock-In

James DiGioia wrote a post recently about the changes to using the pipeline operator (|&gt;).

The main point in the post is that the proposal itself is in flux and has a few options to explore. Because we’d like to implement all three of the current possibilities as Babel plugins for both spec feedback and user feedback, we believed the way the plugin is used should change as well. This is a relatively new approach for TC39 and Babel!

Previously, we would add the proposal plugin to the config and that was it. Now, we remove the default behavior and ask users to opt into a flag that shows which proposal is chosen. We make it clear that there isn’t a fixed (or even favored) option at the moment.

This is something that we’d like to continue to do moving forward as another indication that these proposals are open to change and feedback from all of us. The removal of the Stage presets makes this even easier, as before we had to pass down these options even if you didn’t use the syntax.

Ecosystem Maintenance Burden

A language’s “syntax budget” doesn’t just apply to the complexity of the language itself but can extend down to the tooling. Each new syntax addition brings a new burden to the maintainers of other JavaScript projects.

Once new syntax is proposed, many things need updating: parsers (babylon), syntax highlighting (language-babel), linters (babel-eslint), test frameworks (jest/ava), formatters (prettier), code coverage (istanbul), minifiers (babel-minify), and more.

There have been many issues brought up on projects like acorn, eslint, jshint, typescript, and others to support Stage 0 proposals because they were in Babel. There aren't many projects that would adhere to a policy that required them to support any proposal, since that would be extremely demanding to maintain. In many ways, it's surprising we even attempt to handle it in Babel itself given the constant updates and churn.

Who is doing that work, and is it our responsibility to make sure everything works? Every one of those projects (mostly volunteers) is lacking in help in almost every aspect, and yet we continually get complaints about this across the board. How are we, as a community, to take responsibility for dealing with our infrastructure (not dissimilar to open source as a whole)?

Babel has taken on the unusual burden of supporting these experimental features. At the same time, it’s reasonable that other projects take a more conservative policy. If you’d like to see new language features are supported across the ecosystem, contribute to TC39 and this project to bring these proposals to Stage 4.

The Future

The purpose of this project is to act as a part of the TC39 process: being a resource for both implementing newer (Stage 0–2) proposals and receiving feedback from users while also supporting older versions of JavaScript. We hope this post sheds more light on how we are trying, as best we can, to better align this project in the JavaScript ecosystem. We will be releasing a RC for v7 soon!

If you appreciate this post and the work we’re doing on Babel, you can support me on Patreon, ask your company to sponsor us on Open Collective, or better yet get your company involved with Babel as part of your work. We’d appreciate the collective ownership.

With thanks to all the reviewers! Feel free to give feedback on Twitter.

Originally published at https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets.

6 months later, the actual release https://twitter.com/left_pad/status/1034204330352500736!

Hey there ?! I’m Henry, one of the maintainers on Babel.

EDIT: I’ve left Behance and have made a Patreon to try to pursue working on open source full time, please consider donating (ask your company).

A quick intro to Babel

Some people like to think of Babel as a tool that lets you write ES6 code. More specifically, a JavaScript compiler than will convert ES6 into ES5 code. That was pretty fitting back when its name was 6to5, but I think Babel has become a lot more than that.

Now let’s back up a bit. The reason why this is even necessary in the first place is because, unlike most languages on the server (even Node.js), the version of JavaScript that you can run depends on your specific browser version. So it doesn’t matter if you are using the latest browsers if your users (that you want to keep) are still on IE. If you want to write the class A {} , for example, then you’re out of luck — some number of your users will get a SyntaxError and a white page.

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

But it doesn’t just stop at “ES6” (some people like to say ES2015). Babel has certainly expanded upon its initial goal of only compiling ES6 code, and now compiles whatever ES20xx version you want (the latest version of JavaScript) to ES5.

The ongoing process

One of the interesting things about the project is that, as long as new JavaScript syntax is added, Babel will need to implement a transform to convert it.

But you might be thinking, why should we even send a compiled version (larger code size) to browsers that do support that syntax? How do we even know what syntax each browser supports?

Well, we made [babel-preset-env](https://babeljs.io/docs/en/babel-preset-env) to help with that issue by creating a tool that lets you specify which browsers you support. It will automatically only transform the things that those browsers don’t support natively.

Beyond that, Babel (because of its usage in the community) has a place in influencing the future of the JavaScript language itself! Given that it is a tool for transforming JS code, it can also be used to implement any of the proposals submitted to TC39 (Ecma Technical Committee 39, the group that moves JavaScript forward as a standard).

There is a whole process a “proposal” goes through, from Stage 0 to Stage 4 when it lands into the language. Babel, as a tool, is in the right place to test out new ideas and to get developers to use it in their applications so they can give feedback to the committee.

This is really important for a few reasons: the committee wants to be confident that the changes they make are what the community wants (consistent, intuitive, effective). Implementing an unspecified idea in the browser is slow (C++ in the browser vs. JavaScript in Babel), costly, and requires users to use a flag in the browser versus changing their Babel config file.

Since Babel is so ubiquitous, there is a good chance that real usage will occur. This will make the proposal much better off than if it was just implemented without any vetting from the developer community at large.

And it is not just useful in production. Our online REPL is useful for people learning JavaScript itself, and allows them to test things out.

I think Babel is in a great position to be an educational tool for programmers so they can continue to learn how JavaScript works. Through contributing to the project itself, they’ll learn many other concepts such as ASTs, compilers, language specification, and more.

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

My story

Those are some of the reasons I get excited to work on this project each day, especially as a maintainer. Most of the current maintainers, including myself, didn’t create the project but joined a year after — and it’s still mindblowing to think 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 sponsor half my time on Babel.

Sometimes “maintaining” just means fixing bugs, answering questions on our Slack or Twitter, or writing a changelog (it’s really up to each of us). But recently, I’ve decreased my focus on making bug fixes and features. Instead, I’ve been putting some time into thinking about more high level issues like: what’s the future of this project? How do we grow our community in terms of the number of maintainers versus of the number of users? How can we sustain the project in terms of funding? Where do we fit in the JavaScript ecosystem as a whole (education, TC39, tooling)? And is there a role for us to play in helping new people join in open source (RGSoC and GSoC)?

Because of these questions, what I’m most excited about with this release isn’t necessarily the particulars in the feature set (which are many: initial implementations of new proposals like the Pipeline Operator (a |> b), a new TypeScript preset with help from the TS team, and .babelrc.js files).

Rather, I’m excited about what all those features represent: a year’s worth of hard work trying not to break everything, balancing users’ expectations (why is the build so slow/code output so large, why is the code not spec-compliant enough, why doesn’t this work without configuration, why isn’t there an option for x), and sustaining a solid team of mostly volunteers.

And I know our industry has a huge focus on “major releases,” hyped features, and stars, but that’s just one day that fades. I’d like to suggest we continue thinking about what it takes to be consistent in pushing the ecosystem forward in a healthy fashion.

This could simply mean thinking about the mental and emotional burden of maintainer-ship. It could mean thinking about how to provide mentorship, expectation management, work/life balance advice, and other resources to people wanting to get involved, instead of just encouraging developers to expect immediate, free help.

Diving into the changelog

Well, I hope you enjoy the long changelog ?. If you’re interested in helping us out, please let us know and we’d be glad to talk more.

We started a new videos page, since people wanted to learn more about how Babel works and contribute back. This page contains videos of conference talks on Babel and related concepts from team members and people in the community.

We also created a new team page! We will be updating this page in the future with more information about what people work on and why they are involved. For such a large project, there are many ways to get involved and help out.

Here are some highlights and quick facts:

• Babel turned 3 years old on September 28, 2017!
• Daniel moved babel/babylon and babel/babel-preset-env into the main Babel monorepo, babel/babel. This includes all Git history, labels, and issues.
• We received a $1k/month donation from Facebook Open Source!
• This the highest monthly donation we have gotten since the start (next highest is $100/month).
• In the meantime, we will use our funds to meet in person and to send people to TC39 meetings. These meetings are every 2 months around the world.
• If a company wants to specifically sponsor something, we can create separate issues to track. This was difficult before, because we had to pay out of pocket or find a conference to speak at during the same week to help cover expenses.

How you can help

If your company would like to give back by supporting a fundamental part of JavaScript development and its future, consider donating to our Open Collective. You can also donate developer time to help maintain the project.

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

Engineer: There's a thing in SQL Server Enterprise blocking us
Company: Let's set up a call next week with them an ongoing discussion to resolve it next quarter

Engineer: There's a thing we need in babel, can I spent 2 days with a PR for it
Company: lol no it's their job https://t.co/icgaoJ0dTe

— Shiya (@ShiyaLuo) November 16, 2017

The best thing for Babel is finding people who are committed to helping out with the project, given the massive amount of work and responsibility it requires. Again, I never felt ready to be a maintainer, but somehow stumbled upon it. But I’m just one person, and our team is just a few people.

#2: Help fund development

Company: "We'd like to use SQL Server Enterprise"
MS: "That'll be a quarter million dollars + $20K/month"
Company: "Ok!"
...
Company: "We'd like to use Babel"
Babel: "Ok! npm i babel --save"
Company: "Cool"
Babel: "Would you like to help contribute financially?"
Company: "lol no"

— Adam Rackis (@AdamRackis) November 16, 2017

We definitely want to be able to fund people on the team so they can work full-time. Logan, in particular, left his job a while ago and is using our current funds to work on Babel part time.

#3 Contribute in other ways ?

For example, Angus made us an official song!

Upgrading

We will also be working on an upgrade tool that will help rewrite your package.json/.babelrc files and more. Ideally, this means it would modify any necessary version number changes, package renames, and config changes.

Please reach out to help and to post issues when trying to update. This is a great opportunity to get involved and help the ecosystem update!

Summary of the previous post

• Dropped Node 0.10/0.12/5 support.
• Updated TC39 proposals
• Numeric Separator: 1_000
• Optional Chaining Operator: a?.b
• import.meta (parseble)
• Optional Catch Binding: try { a } catch {}
• BigInt (parseble): 2n
• Split export extensions into export-default-from and export-ns-form
• .babelrc.js support (a config using JavaScript instead of JSON)
• Added a new Typescript Preset and separated the React/Flow presets
• Added JSX Fragment Support and various Flow updates
• Removed the internal babel-runtime dependency for smaller size

Newly updated TC39 proposals

• Pipeline Operator: a |> b
• Throw Expressions: () => throw 'hi'
• Nullish Coalescing Operator: a ?? b

Deprecated yearly presets (e.g. babel-preset-es20xx)

TL;DR: use babel-preset-env.

What’s better than you having to decide which Babel preset to use? Having it done for you, automatically!

Even though the amount of work that goes into maintaining the lists of data is humongous — again, why we need help — it solves multiple issues. It makes sure users are up to date with the spec. It means less configuration/package confusion. It means an easier upgrade path. And it means fewer issues about what is what.

babel-preset-env is actually a pretty old preset that replaces every other syntax preset that you will need (es2015, es2016, es2017, es20xx, latest, and so on).

It compiles the latest yearly release of JavaScript (whatever is in Stage 4) which replaces all the old presets. But it also has the ability to compile according to target environments you specify: it can handle development mode, like the latest version of a browser, or multiple builds, like a version for IE. It even has another version for evergreen browsers.

Not removing the Stage presets (babel-preset-stage-x)

Frustration level if we remove the Stage presets in Babel? (in favor explicitly requiring proposal plugins since they aren't JavaScript yet)

— Henry Zhu (@left_pad) June 9, 2017

We can always keep it up to date, and maybe we just need to determine a better system than what the current presets are.

Right now, stage presets are just a list of plugins that we manually update after each TC39 meeting. To make this manageable, we need to allow major version bumps for these “unstable” packages. This is partly because the community will re-create these packages anyway. So we might as well do it from an official package, and then have the ability to provide better messaging and so on.

Renames: Scoped Packages (@babel/x)

Here is a poll I put out almost a year ago:

Thoughts on @babeljs using npm scoped packages for 7.0?

— Henry Zhu (@left_pad) January 18, 2017

Back then, not a lot of projects used scoped packages, so most people didn’t even know they existed. You might have had to pay for an npm org account back then, whereas now it is free (and supports non-scoped packages, too).

The issues with searching for scoped packages are solved, and download counts work. The only stumbling block left is that some 3rd party registries still don’t support scoped packages. But I think we are at a point where it seems pretty unreasonable to wait on that.

Here’s why we prefer scoped packages:

• Naming is difficult: we won’t have to check if someone else decided to use our naming convention for their own plugin
• We have similar issues with package squatting
• Sometimes people create babel-preset-20xx or some other package because it’s funny. We have to make an issue and email to ask for it back.
• People have a legit package, but it happens to be the same name as what we wanted to call it.
• People see that a new proposal is merging (like optional chaining or pipeline operator) and decide to fork and publish a version of it under the same name. Then, when we publish, it tell us the package was already published ?. So I have to find their email and email both them and npm support to get the package back and republish.
• What is an “official” package and what is a user/community package with the same name? We get issue reports of people using misnamed or unofficial packages because they assumed it was part of Babel. One example of this was a report that babel-env was rewriting their .babelrc file. It took them a while to realize it wasn't babel-preset-env.

So, it seems pretty clear that we should use scoped packages, and, if anything, we should have done it much earlier ?!

Examples of the scoped name change:

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

Renames: -proposal-

Any proposals will be named with -proposal- now to signify that they aren't officially in JavaScript yet.

So @babel/plugin-transform-class-properties becomes @babel/plugin-proposal-class-properties, and we would name it back once it gets into Stage 4.

Renames: Drop the year from the plugin name

Previous plugins had the year in the name, but it doesn’t seem to be necessary now.

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

Since years were only used for es3/es2015, we didn’t change anything from es2016 or es2017. However, we are deprecating those presets in favor of preset-env, and, for the template literal revision, we just added it to the template literal transform for simplicity.

Peer dependencies and integrations

We are introducing a peer dependencies on @babel/core for all the plugins (@babel/plugin-class-properties), presets (@babel/preset-env), and top level packages (@babel/cli, babel-loader).

peerDependencies are dependencies expected to be used by your code, as opposed to dependencies only used as an implementation detail. — Stijn de Witt via StackOverflow.

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

For tools that already have a peerDependency on babel-core and aren't ready for a major bump (since changing the peer dependency is a breaking change), we have published a new version of babel-core to bridge the changes over with the new version babel-core@7.0.0-bridge.0. For more information, check out this issue.

Similarly, packages like gulp-babel, rollup-plugin-babel, and so on all used to have babel-core as a dependency. Now these will just have a peerDependency on @babel/core. Because of this, these packages don’t have to bump major versions when the @babel/core API hasn't changed.

#5224: independent publishing of experimental packages

I mention this in The State of Babel in the Versioning section. Here’s the Github Issue.

You might remember that after Babel 6, Babel became a set of npm packages with its own ecosystem of custom presets and plugins.

Since then, however, we have always used a “fixed/synchronized” versioning system (so that no package is on v7.0 or above). When we do a new release, such as v6.23.0 , only packages that have updated code in the source are published with the new version. The rest of the packages are left as is. This mostly works in practice because we use ^ in our packages.

Unfortunately, this kind of system requires a major version to be released for all packages once a single package needs it. This either means that we make a lot small breaking changes (unnecessary), or we batch lots of breaking changes into a single release. Instead, we want to differentiate between the experimental packages (Stage 0, and so on) and everything else (es2015).

Because of this, we intend to make major version bumps to any experimental proposal plugins when the spec changes, rather than waiting to update all of Babel. So anything that is < Stage 4 would be open to breaking changes in the form of major version bumps. The same applies to the Stage presets themselves (if we don’t drop them entirely).

This goes along with our decision to require TC39 proposal plugins to use the -proposal- name. If the spec changes, we will do a major version bump to the plugin and the preset it belongs to (as opposed to just making a patch version which may break for people). Then, we will need to deprecate the old versions and setup an infrastructure which will automatically update people so that they’re up to date on what the spec will become (and so they don't get stuck on something. We haven’t been so lucky with decorators.).

The env option in .babelrc is not being deprecated!

Unlike in the last post, we just fixed the merging behavior to be more consistent.

The configuration in env is given higher priority than root config items. And instead of the weird approach of just using both, plugins and presets now merge based on their identity, so you can do this:

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

with BABEL_ENV=test . It would replace the root env config with the one from test, which has no options.

Support [class A extends Array](https://twitter.com/left_pad/status/940723982638157829) (oldest caveat)

Babel will automatically wrap any native built-ins like Array, Error, and HTMLElement so that doing this just works when compiling classes.

Speed

• Many fixes from bmeurer on the v8 team!
• 60% faster via the web-tooling-benchmark https://twitter.com/left_pad/status/927554660508028929

preset-env: "useBuiltins": "usage"

babel-preset-env introduced the idea of compiling syntax to different targets. It also introduced, via the useBuiltIns option, the ability to only add polyfills that the targets don't support.

So with this option, something like:

import "babel-polyfill";

can turn into

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

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

But in order to make that even better, we should only import polyfills that are “used” in the codebase itself. Why import padStart if it is not even used in the code?

"useBuiltins": "usage" is our first attempt to tackle that idea. It performs an import at the top of each file, but only adds the import if it finds it used in the code. This approach means that we can import the minimum amount of polyfills necessary for the app (and only if the target environment doesn't support it).

So if you use Promise in your code, it will import it at the top of the file (if your target doesn't support it). Bundlers will dedupe the file if it is the same, so this approach won't cause multiple polyfills to be imported.

import "core-js/modules/es6.promise";
var a = new Promise();

import "core-js/modules/es7.array.includes";
[].includes
a.includes

With type inference we can know if an instance method like .includes is for an array or not. Having a false positive is ok until that logic is better, since it is still better than importing the whole polyfill like before.

Misc updates

• [babel-template](https://github.com/babel/babel/blob/master/packages/babel-template) is faster and easier to use
• regenerator was released under the MIT License — it’s the dependency used to compile generators/async
• “lazy” option to the modules-commonjs plugin via #6952
• You can now use envName: "something" in .babelrc or pass via cli babel --envName=something instead of having to use process.env.BABEL_ENV or process.env.NODE_ENV
• ["transform-for-of", { "assumeArray": true }] to make all for-of loops output as regular arrays
• Exclude transform-typeof-symbol in loose mode for preset-env #6831
• Landed PR for better error messages with syntax errors

To-dos Before Release

• Handle [.babelrc](https://github.com/babel/babel/issues/6766) lookup (want this done before first RC release)
• “overrides” support: different config based on glob pattern
• Caching and invalidation logic in babel-core.
• Better story around external helpers.
• Either implement or have a plan in place for versioning and handling polyfills independently from helpers, so we aren’t explicitly tied to core-js 2 or 3. People may have things that depend on one or the other, and won’t want to load both a lot of the time.
• Either a working decorator implementation, or functional legacy implementation, with clear path to land current spec behavior during 7.x’s lifetime.

Thanks

Shoutout to our team of volunteers:

Logan has been really pushing hard to fix a lot of our core issues regarding configs and more. He’s the one doing all of that hard work.

Brian has been taking over maintenance of a lot of preset-env work and whatever else I was doing before ?

Daniel has always stepped in when we need the help, whether it be maintaining babel-loader or helping move the babylon/babel-preset-env repo’s over. And same with Nicolo, Sven, Artem, and Diogo who have stepped up in the last year to help out.

I’m really looking forward to a release (I’m tired too — it’s almost been a year ?). But I also don’t want to rush anything just because. There’s been a lot of ups and downs throughout this release, but I’ve certainly learned a lot and I’m sure the rest of the team has as well.

And if I’ve learned anything at all this year, I should really heed this advice rather than just write about it.

"Before you go maintaining anything else, maintain your own body first" - Mom ?

— Henry Zhu (@left_pad) December 22, 2017

Also thanks to Mariko for the light push to actually finish this post (2 months in the making)