What's the difference between babel-preset-stage-0, babel-preset-stage-1 etc?

Solution 1:

Babel's stage presets equate to the TC39 Process and the different states of each proposal for a potential language change. They include implementations and polyfills for all of the proposed changes in that stage.

Anything currently in Stage-0 is Strawman, not ES6. It is future Javascript and absolutely not certain that it will ever make it into any official ECMAScript specification.

Please do not just set to stage-0 so it will work without understanding the consequences this will have.

The Babel Preset which contains only ES6 features is preset-es2015

Solution 2:

As mostly elaborated by other answers. Stage 4 is most Stable and Stage 0, the most dangerous. Here is a bit of a breakdown at a high level for the 5 stages from the previous answers and the documentation. I'm adding this because when I came to this I was expecting a more high-level break down of what each stage is:

Ready for inclusion in ECMAScript Standard, has passed testing and will be part of the next revision

Includes a full spec text and includes plugins that have mostly been tested and provided with feedback. Solution is complete and all further changes are based on implementation experience.

Further support for plugins completed as much as possible. Requirements for these are met mostly with only incremental changes on the way. Semantics and api is expected to be complete. It will most likely become part of the spec.

Each level is inclusive whereas 4 includes 3 includes 2 and so on... I hope that this summation helps someone in the future.

Solution 3:

The stages represent the stages as defined by the TC39 process that works features from crazy but useful ideas into accepted standards, such as ES6. The process takes some time, as every corner case must be discussed, thought about, tested, polyfilled, discussed some more, etc. That is, it is a standards body. The goal is that saying "ES6" will have a full and complete meaning, much as saying "ES5" does.

In practice, your project requirements may range from staying to the tried and true to playing around with oh-so-convenient, if nebulous, language features. You probably want to start with these links:

• The TC39 Process Overview: This includes a nifty chart as to what the stages mean and how features progress from stage to stage. Below that is an overview of TC39.

• The Active Proposals: A quick overview of what stage certain proposals are in. It also includes links to the Finished, Inactive, and Stage 0 proposals. Today, April 2017, Public Class Fields is in stage 2, meaning it is precisely described and reviewers have been assigned, but is not fully reviewed.

• The Babel Preset Package for Stage 3: The plug-in page, with links to Git and NPM, for all Stage 3 proposals. Basically, this plug-in pulls in the collection of packages that, in theory, polyfill the current proposals in TC39 stage 3. In practice, bugs may occur. Also, you can find the similar Similarly, it links to the plug-in pages for Stage 2 and below. Those pages will link to packages that include both Stage 3 proposals and less stable proposals.

• Babel Preset 'env': This Babel preset supports completed proposals, selecting the correct packages needed to support these features in a known environment. For example, a local node executable requires fewer plugins than an older browser. It can be thought of the 'stage-4' plugin that supports approved future features.

In summary, you only need to deal with these prerelease features if you use them. If you do need to use them, pick the highest number of stage that has what you need. If you just want an toy installation with crazy features to discuss around the water cooler, go ahead and grab stage 0.

Solution 4:

This is the best starting point to understand. What are babel presets

An excerpt from the link:

Stage 0 - Strawman: just an idea, possible Babel plugin.
Stage 1 - Proposal: this is worth working on.
Stage 2 - Draft: initial spec.
Stage 3 - Candidate: complete spec and initial browser implementations.
Stage 4 - Finished: will be added to the next yearly release

Overall Picture:

1. With time Javascript is evolving and more and more features are being added to the language.
2. The browsers also have to do a lot of work so that they can implement these new features to be understood by them. This process in general is a lot slower than the pace Javascript is evolving.
3. But developers want to use the new features of language since it make it easier for them to write, understand, maintain the code.
4. So developers write their code using the new Javascript features, but before that code reaches browsers, it goes through a build process where using some magic, all the code with new features is transpiled into code understandable by browser. i.e. new features of Javascript but coded using the browser understandable constructs of language.
5. The build magic can be performed using tools, one of them being Babel.
6. The way Babel works is that it takes a set of plugins. Each of these plugin could refer to transforming a particular new feature of Javscript into browser understandable constructs of language.
7. There are hundreds of such plugins, each one referring to different new features of Javascript. These features may or may not be part of the final Javascript spec. And if it never ends up going to final Javascript spec, none of the browsers will implement this feature. So if any developer uses any experimental feature of JS using babel plugin, its the risk that he/she is taking. If it never ends up in spec, that part of code will always have to be transpiled before its deployed to browsers.
8. This risk is categorised into various levels to signify the chances of any feature reaching the final spec.
9. Also babel has grouped these plugins into various sets, which is called a preset in babel's terms. And each preset contains plugins from various levels of risk.
10. preset-0 It means it has plugins for features which are very experimental and hence at high risk of making it out to final spec. Its like an idea that came to a developer that Javascript should have a particular feature, and he did some work to get it to TC-39 proposal process.
11. preset-1 It contains the plugins for the feature ideas accepted by the TC-39, and they find it worth working on.
12. preset-2 Plugins for features where an initial draft is ready for the feature. And it goes on..

So it could happen that a feature in Stage 0 reached Stage 2 in some time and end up being in next release of Javascript some more time later.

Hence with each version of these Babel Presets, you could find different set of plugins in it. It could also happen that a feature in stage 0 went through some changes and it made breaking changes into how it functions. And it reached, lets say stage-2 with a totally different API. So developers have to make sure that when they are updating these plugins they make necessary changes to their code.