Planning for 7.0 #1166
Planning for 7.0 #1166
Conversation
hzoo
force-pushed
the
pre-7.0-post
branch
3 times, most recently
from
1833c41
to
01159b0
Compare
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| When OSS maintainers want to move the project forward and make breaking changes, it may come at the cost of more hassle for their users. | ||
|
|
||
| A major version bump *is* just a number, but it can cause unnecessary pain for users/library authors (including ourselves since we'd want to upgrade Babel itself to run on Babel 7 at some point right). We didn't want to do it just for this change. |
There was a problem hiding this comment.
What about:
Progress and moving forward in OSS projects often come with the cost of hassle and pain for its users. Because of this, we're always been hesitant in making the choice to introduce a major version bump/breaking changes. But by dropping Node v0.12, we can not only make a number of improvements to the codebase, but also upgrade dependencies and tools (ESLint, Yarn, Jest, Lerna, etc).
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| ### [#5128](https://github.com/babel/babel/issues/5128) Babel presets must export a function as the default export | ||
|
|
||
| We want to standardize on requiring presets to be functions that return a Babel config object (rather than just the object). |
There was a problem hiding this comment.
"We want to" seems like we're considering it... what about:
To simplify things, we've decided to standardize on requiring presets be functions that return a Babel config object (rather than just an object).
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| ### [#5218](https://github.com/babel/babel/pull/5218) Remove `babel-runtime` from Babel dependencies | ||
|
|
||
| Babel itself doesn't have that many external dependencies, but in 6.x [each package has a dependency on `babel-runtime`](https://github.com/babel/babel/blob/958f72ddc28e2f5d02adf44eadd2b1265dd0fa4d/packages/babel-plugin-transform-es2015-arrow-functions/package.json#L12) so that we can use built-ins such as `Symbol`, `Map`, `Set` without using a polyfill. By changing the minimum supported version of Node to v4 (where those built-ins are supported natively), we can drop the dependency entirely. |
There was a problem hiding this comment.
Babel itself doesn't have many external dependencies, but in 6.x each package has a dependency on
babel-runtimeso that built-ins likeSymbol,Map,Set, and others are available without needing a polyfill.
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| Babel itself doesn't have that many external dependencies, but in 6.x [each package has a dependency on `babel-runtime`](https://github.com/babel/babel/blob/958f72ddc28e2f5d02adf44eadd2b1265dd0fa4d/packages/babel-plugin-transform-es2015-arrow-functions/package.json#L12) so that we can use built-ins such as `Symbol`, `Map`, `Set` without using a polyfill. By changing the minimum supported version of Node to v4 (where those built-ins are supported natively), we can drop the dependency entirely. | ||
|
|
||
| > This is an issue on npm 2 (we didn't recommended it's use with Babel 6) and yarn, but not npm 3 due to it's deduping behavior. |
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| > This is an issue on npm 2 (we didn't recommended it's use with Babel 6) and yarn, but not npm 3 due to it's deduping behavior. | ||
|
|
||
| With [Create React App](https://github.com/facebookincubator/create-react-app) the size varied greatly based on if `babel-runtime` was hoisted. |
There was a problem hiding this comment.
the size of the
node_modulesfolder changed drastically whenbabel-runtimewas hoisted.
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| > For more specific changes, please check out our upgrade guide (will be updated)! | ||
|
|
||
| ## 💥 Breaking Changes |
There was a problem hiding this comment.
Couldn't we link the Breaking change section to the upgrade blog post? #1146
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| ### [#4315](https://github.com/babel/babel/issues/4315) Drop support for unmaintained Node versions: 0.10, 0.12, 5 | ||
|
|
||
| Progress in OSS projects often comes at the cost of upgrading for its users. Because of this, we're always been hesitant in making the choice to introduce a major version bump/breaking changes. But by dropping Node v0.12, we can not only make a number of improvements to the codebase, but also upgrade dependencies and tools (ESLint, Yarn, Jest, Lerna, etc). |
_posts/2017-02-14-whats-in-7.0.md
Outdated
| > I mention this in [The State of Babel](http://babeljs.io/blog/2016/12/07/the-state-of-babel#the-future-versioning). | ||
| > https://github.com/babel/babylon/issues/275 | ||
|
|
||
| You might remember than after Babel 6, Babel became a set of npm packages with it's own ecosystem of custom presets and plugins. |
There was a problem hiding this comment.
than -> that
it's -> its
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| However since then, we've 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 while 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 that a major version be released for all packages once a single package needs it. This either means we make a lot small breaking changes (unncessary) or we batch lots of breaking changes into a single release. This is the same issue for a single package/repo but we have a way out: since Babel is a monorepo of npm packages, we can actually publish breaking changes in individual packages if necessary. |
There was a problem hiding this comment.
unncessary -> unnecessary
_posts/2017-02-14-whats-in-7.0.md
Outdated
| https://github.com/babel/babel/issues/5276 | ||
| > https://github.com/babel/babel/issues/5276 | ||
|
|
||
| The "env" option (not [babel-preset-env](https://github.com/babel/babel-preset-env)) can be confusing to use and we've had a lot of issues reported since it was wasn't intuitive to users as well as some bugs. |
There was a problem hiding this comment.
Actually, how about:
The "env" configuration option (not to be confused with babel-preset-env) has been a source of confusion for our users as seen by the numerous issues reported.
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| The [current behavior](http://babeljs.io/docs/usage/babelrc/#env-option) is to merge the config values into the top level values which isn't always intuitive such that developers end up putting nothing in the top level and just duplicating all the presets/plugins under separate envs. | ||
|
|
||
| Instead of all this maybe we should just introduce a JS config format for anything more complicated than simple JSON (instead of complex behavior + other format's like YAML). |
There was a problem hiding this comment.
To eliminate the confusion (and also help some of our users with more advanced customization needs), we're considering dropping the
envconfig option all together and recommending users use the proposed JS config format (see below).
_posts/2017-02-14-whats-in-7.0.md
Outdated
| module.exports = { plugins }; | ||
| ``` | ||
|
|
||
| Either way, it seems both simple and straightfoward to write this kind of logic (and we could always provided some helper functions for this). |
_posts/2017-02-14-whats-in-7.0.md
Outdated
| > regeneratorRuntime is not defined | ||
| > "regeneratorRuntime is not defined" - reported all the time. | ||
|
|
||
| Basically we need a better around how to deal with built-ins/polyfills. |
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| > "regeneratorRuntime is not defined" - reported all the time. | ||
|
|
||
| Basically we need a better around how to deal with built-ins/polyfills. |
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| The [current behavior](http://babeljs.io/docs/usage/babelrc/#env-option) is to merge the config values into the top level values which isn't always intuitive such that developers end up putting nothing in the top level and just duplicating all the presets/plugins under separate envs. | ||
|
|
||
| Instead of all this maybe we should just introduce a JS config format for anything more complicated than simple JSON (instead of complex behavior + other format's like YAML). |
There was a problem hiding this comment.
Maybe:
To eliminate the confusion (and also help some of our users with more advanced customization needs), we're considering dropping the env config option all together and recommending users use the proposed JS config format (see below).
_posts/2017-02-14-whats-in-7.0.md
Outdated
|
|
||
| > https://github.com/babel/babel/issues/5276 | ||
|
|
||
| The "env" option (not [babel-preset-env](https://github.com/babel/babel-preset-env)) can be confusing to use and we've had a lot of issues reported since it wasn't intuitive to users as well as some bugs. |
There was a problem hiding this comment.
How about:
The "env" configuration option (not to be confused with babel-preset-env) has been a source of confusion for our users as seen by the numerous issues reported.
hzoo
force-pushed
the
pre-7.0-post
branch
4 times, most recently
from
8d31ecd
to
461e991
Compare
|
|
||
| However since then, we've 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 while 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 that a major version be released for all packages once a single package needs it. This either means we make a lot small breaking changes (unnecessary) or we batch lots of breaking changes into a single release. This is the same issue for a single package/repo but we have a way out: since Babel is a monorepo of npm packages, we can actually publish breaking changes in individual packages if necessary. |
There was a problem hiding this comment.
Instead of "we can actually publish breaking changes in individual packages if necessary." just go with the summary from the "This just means" section and lead with making major version updates. If you lead with breaking changes folks will panic before getting to the next paragraph.
There was a problem hiding this comment.
Made some changes + an example
| - Still unsupported on certain non-npm tools (lock-in) | ||
| - No download counts unless we alias back to old names | ||
|
|
||
| Sounds like we may want to defer, and in the very least it's not a breaking change given it's a name change. |
There was a problem hiding this comment.
Do you use download counts for anything really though? You all know Babel is popular, there is no direct competition, and development is still active so no need to check if there's a decline.
Also you could raise these concerns with npm as a potential blocker for adoption.
There was a problem hiding this comment.
@jdalton Yeah I don't have to say this - I was just writing down what others said in the tweet as cons. We don't use downloads for anything
There was a problem hiding this comment.
You can still get dependency count metrics with something like npmrank. I always wanted to use scoped packages for Lodash's individual packages but held off until they could migrate existing ones over (and redirect). That never happened and I eventually dropped them in v5 planning.
There was a problem hiding this comment.
until they could migrate existing ones over (and redirect)
Oh I didn't know that was planned as a thing. I was going to rewrite the old ones to point to the scoped ones as a workaround.
Either way sounds like we aren't going to do it anytime soon
| > It's annoying making a yearly preset (extra package/dependency, issues with npm package squatting unless we do scoped packages) | ||
|
|
||
| Developers shouldn't even need to make the decision of what yearly preset to use? If we drop/deprecate these presets then everyone can use [babel-preset-env](https://github.com/babel/babel-preset-env) instead which will already update as the spec changes. | ||
|
|
|
|
||
| Babel itself doesn't have that many external dependencies, but in 6.x [each package has a dependency on `babel-runtime`](https://github.com/babel/babel/blob/958f72ddc28e2f5d02adf44eadd2b1265dd0fa4d/packages/babel-plugin-transform-es2015-arrow-functions/package.json#L12) so that built-ins like Symbol, Map, Set, and others are available without needing a polyfill. By changing the minimum supported version of Node to v4 (where those built-ins are supported natively), we can drop the dependency entirely. | ||
|
|
||
| > This is an issue on npm 2 (we didn't recommended it's use with Babel 6) and older yarn, but not npm 3 due to its deduping behavior. |
| <blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Thoughts on <a href="https://twitter.com/babeljs">@babeljs</a> using npm scoped packages for 7.0?</p>— Henry Zhu (@left_pad) <a href="https://twitter.com/left_pad/status/821551189166878722">January 18, 2017</a></blockquote> | ||
| <script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script> | ||
|
|
||
| Seems like most who understood what scoped packages were was in favor? |
There was a problem hiding this comment.
s/were was/are were/
| module.exports = { plugins }; | ||
| ``` | ||
|
|
||
| Either way, it seems both simple and straightfoward to write this kind of logic (and we could always provide some helper functions for this). |
There was a problem hiding this comment.
typo: straightforward
|
You might be interested in showing the percentage of folks on each version like this. |
|
@jdalton where do I get that info? I just know from npm-stat that it's 6 mil/month on Babel 6 and 600k/month on Babel 5 |
hzoo
force-pushed
the
pre-7.0-post
branch
2 times, most recently
from
dc251f6
to
b602dd1
Compare
|
|
||
| Developers don't actually know what features are in what version of JavaScript (and they shouldn't have to know). However it is a problem when we all start thinking that "features" that are actually still proposals are in the spec already. | ||
|
|
||
| Many open source projects (including Babel still 😝), tutorials, conference talks, etc all use `stage-0`. React promotes the use of JSX, class properties (currently Stage 2), object rest/spread (now Stage 3) and we all believe that it's just JavaScript because Babel compiled it for them. So maybe removing this abstraction would help people understand more about what is going on and the tradeoffs one is making when choosing to use Stage X plugins. |
There was a problem hiding this comment.
"class properties (currently Stage 2)" should update this to say stage 3?
There was a problem hiding this comment.
Yeah that part was copied over from the first post in feb, and we aren't deprecating so I forgot to check.
|
|
||
| ### Stage 3: Class Properties (from Stage 2) | ||
|
|
||
| > `babel-plugin-transform-class-properties`: the default behavior is now what was previously the "spec" option, which uses `Object.defineProperty` instead of simple assignment. |
There was a problem hiding this comment.
perhaps worth mentioning the impact this has on compat with the current transform-decorators here?
|
|
||
| Before we go into that, I just want to repeat again what the purpose of Babel is. | ||
|
|
||
| As Babel as been transformed from 6to5, browsers have been implementing more of the spec, and users are more comfortable with using the latest syntax/build tooling, Babel's goals haven't changed too much. |
|
|
||
| Our two goals are hand and hand: help developers transform new syntax into backwards compatible code (abstract browser support away), and be a bridge to help TC39 get feedback on new ECMAScript proposals and for the community to have a say in the future of the language. | ||
|
|
||
| Thus, I think it's an understatement to say that Babel is an vital part of the JavaScript community (almost 10 million downloads a month of `babel-core`) and needs it's support. (The only talks I've tried to give are about this point: [JSConf EU](https://github.com/hzoo/maintaining-an-oss-project), [React Rally](https://github.com/hzoo/so-how-does-babel-even-work), [TC39](https://github.com/hzoo/role-of-babel-in-js)). I'll re-iterate a point I made recently: "What happens when Babel dies"? What happens when the current group of people interested in this project get bored/burned out/move on to other things? (What if it's already happened a lot). What are we going to do about it? |
There was a problem hiding this comment.
...the JavaScript community (almost 10 million downloads a month of
babel-core) and needs its support...
|
|
||
| ## [#4315](https://github.com/babel/babel/issues/4315) Drop support for unmaintained Node versions: 0.10, 0.12, 5 | ||
|
|
||
| Progress in OSS projects often comes at the cost of upgrading for its users. Because of this, we've always been hesitant in making the choice to introduce a major version bump/breaking changes. But by dropping unsupported versions of Node, we can not only make a number of improvements to the codebase, but also upgrade dependencies and tools (ESLint, Yarn, Jest, Lerna, etc). |
There was a problem hiding this comment.
...changes. But by dropping unsupported versions of Node...
Maybe try
...changes. However by dropping...
|
|
||
| As Babel as been transformed from 6to5, browsers have been implementing more of the spec, and users are more comfortable with using the latest syntax/build tooling, Babel's goals haven't changed too much. | ||
|
|
||
| Our two goals are hand and hand: help developers transform new syntax into backwards compatible code (abstract browser support away), and be a bridge to help TC39 get feedback on new ECMAScript proposals and for the community to have a say in the future of the language. |
|
|
||
| Our two goals are hand and hand: help developers transform new syntax into backwards compatible code (abstract browser support away), and be a bridge to help TC39 get feedback on new ECMAScript proposals and for the community to have a say in the future of the language. | ||
|
|
||
| Thus, I think it's an understatement to say that Babel is an vital part of the JavaScript community (almost 10 million downloads a month of `babel-core`) and needs it's support. (The only talks I've tried to give are about this point: [JSConf EU](https://github.com/hzoo/maintaining-an-oss-project), [React Rally](https://github.com/hzoo/so-how-does-babel-even-work), [TC39](https://github.com/hzoo/role-of-babel-in-js)). I'll re-iterate a point I made recently: "What happens when Babel dies"? What happens when the current group of people interested in this project get bored/burned out/move on to other things? (What if it's already happened a lot). What are we going to do about it? |
| } | ||
| ``` | ||
|
|
||
| We're working on a guide for how to setup Typescript and Babel with the Typescript team, which should be finished before the official 7.0 release. |
| - Developers don't know what regenerator-runtime is, they just want to use generators/async functions. | ||
| - Many developers are confused as to why a runtime is needed at all or why Babel doesn't compile `Promise`, `Object.assign`, or some other built-in. | ||
| - Developers are confused with the difference between `transform-runtime` the Babel plugin and the runtime itself, `babel-runtime`. | ||
| - Complaints about generated code size since `babel-polyfill` includes all polyfills (although now we have [`useBuiltIns`](https://github.com/babel/babel-preset-env#usebuiltins)) and no one knowing about `external-helpers` |
There was a problem hiding this comment.
This is indeed a big issue. Anything that can be done about default code size would be awesome.
There was a problem hiding this comment.
Raising consciousness about external-helpers would be great. Such lines as this one do a great job at that, same thing could happen in webpack's loader - this is the reason why I've created this.
Also I was wondering if there could be a better story about sharing helpers between libraries - now its a lot of duplicated code in the community's codebases.
|
|
||
| ### [#5218](https://github.com/babel/babel/pull/5218) Remove `babel-runtime` from our own Babel dependencies | ||
|
|
||
| Babel itself doesn't have that many external dependencies, but in 6.x [each package has a dependency on `babel-runtime`](https://github.com/babel/babel/blob/958f72ddc28e2f5d02adf44eadd2b1265dd0fa4d/packages/babel-plugin-transform-es2015-arrow-functions/package.json#L12) so that built-ins like Symbol, Map, Set, and others are available without needing a polyfill. By changing the minimum supported version of Node to v4 (where those built-ins are supported natively), we can drop the dependency entirely. |
There was a problem hiding this comment.
This would also reduce the confusion around babel-runtime quite a bit.
There was a problem hiding this comment.
FYI this is only for babel itself, not for users though so they'd still need it.
| share_text: "Planning for 7.0" | ||
| --- | ||
|
|
||
| If you didn't know already, we're planning on releasing a 7.0 version soon 🙌 ! Looks like work on 7.0 started back in Feburary when I just wanted to make a release to drop Node 0.10/0.12 support and remove babel-runtime and various other code. Since then we've done releases up to `alpha.20`. |
|
|
||
| > `babel-plugin-transform-class-properties`: the default behavior is now what was previously the "spec" option, which uses `Object.defineProperty` instead of simple assignment. | ||
|
|
||
| > This currently has the effect of breaking the decorators plugin if you try to decorate a class property. You'll need to use the `loose` option to be compatible with the version of decorators in the transform until we release the Stage 2 decorators plugin. |
|
|
||
| // decorator cannot be attached to the export | ||
| @foo | ||
| export default class {} |
There was a problem hiding this comment.
Probably worth having an example with export default @foo class {}, perhaps with added newlines.
|
|
||
| ```js | ||
| import _v from "module"; | ||
| export { _v as v }; |
There was a problem hiding this comment.
(not the README's fault but) why not export { default as v } from "module" 🤔
| }; | ||
| ``` | ||
|
|
||
| This was previously done through the `env` configuration option, which is now deprecated. See [below](#deprecate-the-env-option-in-babelrc) for more details. |
There was a problem hiding this comment.
Probably good to mention the babel 6 forwards-compatible option of having a { "presets": ["./.babelrc.js"] } .babelrc
|
|
||
| > I believe the way we want to go about doing this is to move those packages into the `experimental/` folder in our [monorepo](https://github.com/babel/babel) instead of in `packages/`. | ||
| > Then we should rename all proposals to `babel-plugin-proposal-` instead of `babel-plugin-transform-` | ||
| > Change our publish process (probably through Lerna) to publish the packages in `experimental/` independently. |
There was a problem hiding this comment.
I suppose this part is still a TODO? :D
|
|
||
| ### ~~Deprecate Stage X presets~~ | ||
|
|
||
| > Ok we'll probably keep these and just make major version bumps |
There was a problem hiding this comment.
Why? The linked PRs don't seem related to this at all
| - Developers are confused with the difference between `transform-runtime` the Babel plugin and the runtime itself, `babel-runtime`. | ||
| - Complaints about generated code size since `babel-polyfill` includes all polyfills (although now we have [`useBuiltIns`](https://github.com/babel/babel-preset-env#usebuiltins)) and no one knowing about `external-helpers` | ||
|
|
||
| Can we combine/replace these packages and have an easier, default experience? |
There was a problem hiding this comment.
I wonder how TypeScript does generators 🤔
|
Nice work @hzoo! Maybe plug contributing to the collective (or asking the reader to urge their company to become a sponsor via the collective) at the end? |
|
|
||
| Before we go into that, I just want to repeat again what the purpose of Babel is. | ||
|
|
||
| As Babel has been transformed from 6to5, browsers have been implementing more of the spec, and users are more comfortable with using the latest syntax/build tooling, Babel's goals haven't changed too much. |
There was a problem hiding this comment.
has been transformed
has been renamed?
|
|
||
| Our two goals are hand in hand: help developers transform new syntax into backwards compatible code (abstract browser support away), and be a bridge to help TC39 get feedback on new ECMAScript proposals and for the community to have a say in the future of the language. | ||
|
|
||
| Thus, I think it's an understatement to say that Babel is a vital part of the JavaScript community (almost 10 million downloads a month of `babel-core`) and needs its support. (The only talks I've tried to give are about this point: [JSConf EU](https://github.com/hzoo/maintaining-an-oss-project), [React Rally](https://github.com/hzoo/so-how-does-babel-even-work), [TC39](https://github.com/hzoo/role-of-babel-in-js)). I'll re-iterate a point I made recently: "What happens when Babel dies"? What happens when the current group of people interested in this project get bored/burned out/move on to other things? (What if it's already happened a lot). What are we going to do about it? |
There was a problem hiding this comment.
What happens when Babel dies?
Sounds like it's a question of time (maybe it is), I would rather say: if Babel dies.
|
|
||
| Specific packages: | ||
|
|
||
| <details> |
There was a problem hiding this comment.
The contents w/in <details> are all running on one line.
I suggest something like:
<details>
- `babel` packages in the monorepo should all be >= 7.0.0-beta.0
- `babel-preset-env` should be at least 2.0.0-beta.0
- `babel-eslint` can be >= 8.0.0
- `babel-loader` should be >= 7.0.0 (out of beta since it uses `babel-core` as a peerDependency)
- `grunt-babel` can be >= 7.0.0
- `gulp-babel` can be >= 7.0.0
- `rollup-plugin-babel` can be >= 3.0.2
</details>
Will give you an unordered list w/in the <details>
|
|
||
| Since Babel has been renamed from 6to5, browsers have been implementing more of the spec and users are more comfortable with using the latest syntax/build tooling. It shouldn't be surprisingly however that Babel's goals haven't changed much. | ||
|
|
||
| Our two goals are hand in hand: help developers transform new syntax into backwards compatible code (abstract browser support away), and be a bridge to help TC39 get feedback on new ECMAScript proposals and for the community to have a say in the future of the language. |
There was a problem hiding this comment.
It's kind of hard to read this long sentence. I suggest something formatting with ordered list:
Our two goals are hand in hand:
1. Help developers transform new syntax into backwards compatible code (abstract browser support away)
1. Be a bridge to help TC39 get feedback on new [ECMAScript proposals](https://github.com/tc39/proposals) and for the community to have a say in the future of the language
|
|
||
| Our two goals are hand in hand: help developers transform new syntax into backwards compatible code (abstract browser support away), and be a bridge to help TC39 get feedback on new ECMAScript proposals and for the community to have a say in the future of the language. | ||
|
|
||
| Thus, I think it's an understatement to say that Babel is a vital part of the JavaScript community (almost 10 million downloads a month of `babel-core`) and sorely needs its support. (The only talks I've tried to give are about this point: [JSConf EU](https://github.com/hzoo/maintaining-an-oss-project), [React Rally](https://github.com/hzoo/so-how-does-babel-even-work), [TC39](https://github.com/hzoo/role-of-babel-in-js)). I made recently: "What happens if Babel dies"? What happens when the current group of people interested in this project get bored/burned out/move on to other things? (What if it's already happened?). Are we going to do something about it? I don't want to just ask you to help us, you already are us as users of the project. |
There was a problem hiding this comment.
Is there a link for "What happens if Babel dies"? What is it?
I'd also italicize the last "us":
I don't want to just ask you to help us, you already are _us_ as users of the project.
|
|
||
| We've created a new repo: [babel/proposals](https://github.com/babel/proposals) to track our progress on the various [TC39 Proposals](https://github.com/tc39/proposals) and meetings. | ||
|
|
||
| I also added a [section](https://github.com/babel/proposals#when-does-babel-implement-new-features) about when we accept PRs and new proposals. Our basic thinking is that we will start accepting PRs for anything a TC39 champion is going to present (Stage 0). And we will update them (with your help!) when the spec changes. |
There was a problem hiding this comment.
How about:
There is also a section about [how we accept PRs](https://github.com/babel/proposals#when-does-babel-implement-new-features) and new proposals. Our basic thinking is that we will start accepting PRs for anything a TC39 champion is going to present at the next meeting (Stage 0). And we will update them (with your help!) when the spec changes.
|
|
||
| > `babel-plugin-transform-class-properties`: the default behavior is now what was previously the "spec" option, which uses `Object.defineProperty` instead of simple assignment. | ||
|
|
||
| > This currently has the effect of breaking the legacy decorators plugin if you try to decorate a class property. You'll need to use the `loose` option to be compatible with the version of decorators in the transform until we release the Stage 2 decorators plugin. |
There was a problem hiding this comment.
Can you link "legacy decorators plugin" to https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy ?
|
|
||
| ### Stage 2: Numeric Seperators (new) | ||
|
|
||
| > `babel-plugin-transform-optional-chaining`: make numeric literals more readable by creating a visual separation (a `_`) between groups of digits. |
There was a problem hiding this comment.
I think you meant babel-plugin-transform-numeric-separator. Also a link would be helpful
|
|
||
| ### Stage 2: Decorators (from Stage 1), still WIP | ||
|
|
||
| > `babel-plugin-transform-decorators`: [PR](https://github.com/babel/babel/pull/6107) |
|
|
||
| This was previously done through the `env` configuration option, which is now deprecated. See [below](#deprecate-the-env-option-in-babelrc) for more details. | ||
|
|
||
| --- |
There was a problem hiding this comment.
What exactly is this line dividing? The content below seems related to the content above it, but visually it seems like a hard separation
|
|
||
| To eliminate the confusion (and help our power users), we're considering dropping the env config option all together and recommending users use the proposed JS config format (see below). | ||
|
|
||
| ### Deprecate ES20xx presets |
|
|
||
| ## 🤔 Questions | ||
|
|
||
| ### ~~Deprecate/Rename/Remove Stage X presets~~ |
There was a problem hiding this comment.
I use env + stage-3 + specific plugins. stage-3 is relatively stable although I'm positive I'm only using a small percentage of the transforms there.
Now that we've gotten through that initial "wave" of features, this may make sense. It's probably controversial though.
|
|
||
| ### `external-helpers`, `transform-runtime`, `babel-polyfill` | ||
|
|
||
| > "regeneratorRuntime is not defined" - reported all the time. |
There was a problem hiding this comment.
I believe the situation could be improved with this PR merged in - facebook/regenerator#307
It refactors the regenerator-runtime's code to es6 modules and it contains a change to the regenerator-transform which leverages the former and adds an import statement to the regenerator-runtime (similar thing is done by transform-runtime nowadays).
With that in place I dont know how one would end up with "regeneratorRuntime is not defined" - it just should be defined at all times.
Title: "What's in 7.0"
Should mention our WIP upgrade guide, project sustainability?
Also check out #1146