Create aug-30.md

[hzoo]

Priority: Babel 7

• Remember to label things as breaking so we can document them in the blog post. https://github.com/babel/babel/issues?q=label%3A%22tag%3A+breaking+change%22+is%3Aclosed

PRs

• https://github.com/babel/babel/pull/5710
• https://github.com/babel/babel/pull/4935

Higher level issues (for someone else to tackle)

• https://github.com/babel/babel/issues/6142 brings up the question of what we should do with the flow-comments plugin. It doesn't seem like a thing were we just fix up the bugs but more like it's kinda broken due to the fact that comments are hard to insert (especially with transformed output). I think it requires someone to look into comment attachment in general https://github.com/babel/babel/labels/comment%20attachment.

Internal Stuff

• [ ] Someone should move the 7.0 branch to become master, and make master into 6.x (same with babel-preset-env)
• [ ] We should move babylon back into the monorepo?
  • Reasons: easier release cycle, less chance of breaking stuff (have to have a script in this repo just for the smoke test against babel itself which is unnecessary), easier to write code to transform what is newly parsed (this is forgotten a lot actually), no need to redirect issues to another repo, duplicate issues/labels.
  • It's true the parser is very separate from the rest, but in the end it's specific to Babel else someone can else acorn/esprima/etc. Why have a one-off package; if it's hard to release then it's reason to fix/not use Lerna to release
  • Issue: may want to transfer the git history, and will need to merge the issue labels and issues and prs eventually.
  • Will need to merge the testing frameworks since babylon uses ava, babel uses mocha, and some wanted to use jest (but there was previously issues of it being slow/hard to debug)
• Maybe should move preset-env as well?

[ljharb]

Having all the exit paths from Flow of "to comments", "stripped", and "to runtime checks" are all critical for making it easy to start using Flow, so it'd be really great to keep "to comments" working.

[Daniel15]

babel-standalone build is slow,

That's one reason I kept it as a separate build command rather than bundling it with make build. It's primarily due to the large amount of JS required. Maybe someone more experienced with Webpack can enhance it and make it build more incrementally, or something like that.

[hzoo]

cc @TheLarkInn https://github.com/babel/babel/tree/master/packages/babel-standalone

[Daniel15]

The other thing with babel-standalone is that the build bundles and minifies. This is because I only ever did prod builds of it. Now that it's part of the Babel repo, we only really need to run the minification as part of a release. If node_env is development, we shouldn't bother with minifying.