7 ms·

Babel 7 Released

263 points by dfabulich 8y ago

alexandernst 8y ago
As much as I want to upgrade my projects to Babel 7, I feel that there will be only pain in that road, so... meh
__s 8y ago
Back when Babel 7 became beta I spent an evening switching over the build at work to it. Would sometimes get a build to start failing with webpack where the require code was leaving stray references to undefined module.exports. Shuffling code about & messing with pipeline options would eventually resolve. Bit of speed up was nice. Lo, by now we've replaced Babel entirely with Typescript
- NathanCH 8y ago
  Using beta tools on production? Lesson learned I guess
  - tracker1 8y ago
    Someone has to use the beta tools for real work, otherwise most edge case bugs wouldn't get caught. Yes, there's sometimes pain, and yes sometimes it isn't worth it. Usually it's fine.
STRiDEX 8y ago
Most of my projects now use babel indirectly and its been removed from all backend projects at work, sometimes replaced with typescript or vanilla es6. Ex: anyone using facebook's jest, vue-cli, etc will get v7 whenever those packages upgrade. The typescript support seems interesting for people with large babel pipelines, but I'm not sure what the other use cases are since it doesn't do any of the typechecking tsc does. Would be interested in hearing what people plan to use it for. https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/ https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...
- kevmo314 8y ago
  One benefit of running babel in parallel with tsc is that your execution doesn't depend on your code compiling. Sometimes, for example, if I'm hacking something together, it's faster to just disable type checking all together so I can do what needs to be done and save the type checking until later. Having babel + tsc allows you to do just that instead of having to do all the typing as you go.
  - cowmoo728 8y ago
    tsc in --watch mode still outputs even if there are type errors for precisely this reason. You can ignore the cli warnings and still have everything run in the browser or node while developing.
    - tracker1 8y ago
      Typescript doesn't let me play with stage0-3 features of EcmaScript.
      - tracker1 8y ago
        Replying to myself... looks like typescript now integrates with babel better. May actually convert my latest project next week.
- TheAceOfHearts 8y ago
  I also haven't been using babel for most node projects; V8 has already implemented most of the major features I'm interested in. I don't mind setting up a build tool and configuring everything if the project will be actively maintained or if there's a real need for it, but for smaller projects I think it's better to keep things as simple as possible. It's a huge drag when you later revisit a project and a bunch of dependencies are outdated or broken. One of the holdouts which kept me coming back to babel was JSX, but eventually I learned to love preact and its hyperscript-inspired template function. The code ends up being a bit more verbose but you drastically cut down on dependencies. Babel is still superb if you're targeting a broad range of browsers. Although during development I usually disable babel-loader from Webpack for the improved performance and debugging experience.
lxe 8y ago
Repl (https://babeljs.io/repl https://babeljs.io/repl) seems to still be on 6.26. I wish I could select the babel version on the official online repl, just like https://flow.org/try/ https://flow.org/try/
- alangpierce 8y ago
  In the meantime, looks like you can try out 7.0.0 here: https://babeljs.io/repl/build/7.0/ https://babeljs.io/repl/build/7.0/
  - hzoo 8y ago
    thanks for posting! I personally usually just use https://babeljs.io/repl/build/master https://babeljs.io/repl/build/master!
dergachev 8y ago
Congrats Logan!
cimmanom 8y ago
Will configuration be an less esoteric?
TheAceOfHearts 8y ago
Great job to everyone involved! I've been keeping up with the project since it was 6to5, and these changes look like they'll help clean things up quite a bit and hopefully reduce user confusion. This change might a bit painful for some, but it had to happen. People shouldn't be relying on such early proposals in production. I've been using @babel/preset-env since early on and it's superb. You just pick what platforms you're going to target, and you're pretty much good to go. I'd suggest being a bit weary with automatic polyfills. It's very easy to start using every new feature out there only to have your resulting bundle balloon in size. Depending on the type of project, it might sometimes be better to be explicit about which features can be used, and manually importing those polyfills so you fully understand the price that you're paying. There will probably be some people complaining about complexity and how certain things are still confusing. Although I would agree that there's still room for improvement, targeting multiple independent platforms just seems like it's a challenging problem to solve well. My experiences with cross-compiling native apps have been fairly limited, but when I've tried it I found it far more overwhelming when compared to setting up babel. Perhaps it's just my limited experience in the native space. Am I the only one, or have others shared similar experiences? If you disagree, I'd be very interested in reading about which tools you've used, and examples of ways in which you believe babel could be simplified or improved.
- tracker1 8y ago
  I've been doing two targets on my most recent projects... one for ES2017+ (async support in browser), and another for legacy (IE>=9). Which wasn't too bad for some things... for one of the projects, got to be too much, and I now just do a test for async, and if it fails redirect to "/legacy.html"
  - syspec 8y ago
    What browsers support generators, but do not support await? The polyfill for async, converts those calls to generator functions - however i'm not aware of any browsers which support generator functions, but DO NOT support async/await
    - 8y ago
sugarpile 8y ago
A reminder if you or your org use Babel to consider donating to Henry's patreon (https://www.patreon.com/henryzhu https://www.patreon.com/henryzhu) He's a smart, nice person who plays a large part in software that many of us use on a daily basis. Support open source if you can :)
amasad 8y ago
Really cool to see how far the project has come under Henry's stewardship. A fun story about how I got involved with the project: in Jan 2015 when I was working at Facebook on what would become React Native (was a secret project at the time), I was replacing an ad-hoc in-house built JS transformer and was building my own compiler. But then decided to give this "6to5" thing I've been hearing about a spin -- so I opened my first PR to the project: We're looking into using 6to5 [what Babel was called at the time] for a project at Facebook -- and although we make the library -- the project is stuck for some time on React v0.11 which used a different transform. https://github.com/babel/babel/pull/410 https://github.com/babel/babel/pull/410 Was so impressed by the turnaround time on that PR and the overall quality of the project that I contacted @sebmck to see if we can recruit him to work with us. He was interested and so I referred him to a recruiter. A day later she comes back to me: "did you know this is a 17-year-old kid in the middle-of-nowhere in Australia?" (I didn't). We had to wait until he was 18 before we made him an offer and he joined our team :) (eventually we got all of Facebook.com to run on Babel and not just React Native https://twitter.com/amasad/status/631251607422787584 https://twitter.com/amasad/status/631251607422787584) Like Henry mentions: working on 6.0 was hard and really controversial -- our vision for Babel was to serve as compiler infrastructure for JavaScript (which we've achieved to some extent since so many tools build on top of it and most users use it as part of a bigger toolchain like webpack) but many of our users disagreed with the direction and we were at the receiving end of much vitriol from the community (including here on HN). We're now vindicated (many times over) but goes to show how OSS maintainership can not only be a thankless job, but quite a stressful one too. Thank you Henry and the rest of the team for you dedication.
- slavik81 8y ago
  > We had to wait until he was 18 before we made him an offer Out of curiosity, why was that?
  - augbog 8y ago
    Legal reasons to work in the US have to be 18 I think. Or something with visas
  - 8y ago
tracker1 8y ago
Nice to see this... been sticking with the beta/rc for about a year now. Hopefully some of the edge cases left over (especially wrt webpack) can roll over now.
kylecordes 8y ago
Of course it is great to see this progress, this big pile of improvements in Babel. Babel plus its ecosystem support both a mountain of production code and a remarkable playground in which upcoming language ideas gradually become mainstream. But... While Babel-core isn't overwhelming, the full set of transitive dependencies you get in normal use (with "env") is a lot of code, spread across numerous packages. Many projects care about the provenance of their dependencies, and having a very large number makes such provenance more to think about, more to track down, etc. The voluminous transitive dependencies also make for a slow "npm i" and so on. I've been able to avoid Babel for some use cases: Even when not using types, the TypeScript compiler can handle a broad swath of typical ES-newish to ES-6-or-5 compilation use cases, with a total of 1 dependency (+0 transitive dependencies), quickly. The main downside of this approach is that people look at you funny when you use "tsc" on a non-TypeScript project.
- hzoo 8y ago
  If dependencies are an issue, I would like to make another package that just bundles it all into 1 package (reuse `babel`) so there aren't any "deps" to install but haven't gotten around to doing it, would be a useful contribution opportunity for someone though.
arenaninja 8y ago
I have been using the alpha, beta and rc so far on a project that's scheduled to go live before the end of the year, and @babel/preset-typescript has been a joy to use (minus can't use const enum) Congratulations to the @babel team, this release is hard earned
littlestymaar 8y ago
I really hope this new version is more polished than Babel 6 was at the time of its release. At my former company, the migration to Babel 6 was such a disaster we jokingly renamed it to «Babel Vista».
transfire 8y ago
It is not a COMPILER. It's a TRANSPILER. I got a bit excited for about three seconds until I read the finer print.
- detaro 8y ago
  Transpilers are a type of compiler.
- a_humean 8y ago
  People have long dropped that confusing and often times implied patronising distinction in relation to babel. Its a type of compiler. The direction of travel in terms of abstraction isn't important.
njn 8y ago
This is the most complicated upgrade guide I've ever seen: https://babeljs.io/docs/en/v7-migration https://babeljs.io/docs/en/v7-migration

263 points by dfabulich 8y ago

As much as I want to upgrade my projects to Babel 7, I feel that there will be only pain in that road, so... meh

__s 8y ago

Back when Babel 7 became beta I spent an evening switching over the build at work to it. Would sometimes get a build to start failing with webpack where the require code was leaving stray references to undefined module.exports. Shuffling code about & messing with pipeline options would eventually resolve. Bit of speed up was nice. Lo, by now we've replaced Babel entirely with Typescript

NathanCH 8y ago
Using beta tools on production? Lesson learned I guess
- tracker1 8y ago
  Someone has to use the beta tools for real work, otherwise most edge case bugs wouldn't get caught. Yes, there's sometimes pain, and yes sometimes it isn't worth it. Usually it's fine.

STRiDEX 8y ago

Most of my projects now use babel indirectly and its been removed from all backend projects at work, sometimes replaced with typescript or vanilla es6. Ex: anyone using facebook's jest, vue-cli, etc will get v7 whenever those packages upgrade. The typescript support seems interesting for people with large babel pipelines, but I'm not sure what the other use cases are since it doesn't do any of the typechecking tsc does. Would be interested in hearing what people plan to use it for. https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/ https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...

kevmo314 8y ago
One benefit of running babel in parallel with tsc is that your execution doesn't depend on your code compiling. Sometimes, for example, if I'm hacking something together, it's faster to just disable type checking all together so I can do what needs to be done and save the type checking until later. Having babel + tsc allows you to do just that instead of having to do all the typing as you go.
- cowmoo728 8y ago
  tsc in --watch mode still outputs even if there are type errors for precisely this reason. You can ignore the cli warnings and still have everything run in the browser or node while developing.
  - tracker1 8y ago
    Typescript doesn't let me play with stage0-3 features of EcmaScript.
    - tracker1 8y ago
      Replying to myself... looks like typescript now integrates with babel better. May actually convert my latest project next week.
TheAceOfHearts 8y ago
I also haven't been using babel for most node projects; V8 has already implemented most of the major features I'm interested in. I don't mind setting up a build tool and configuring everything if the project will be actively maintained or if there's a real need for it, but for smaller projects I think it's better to keep things as simple as possible. It's a huge drag when you later revisit a project and a bunch of dependencies are outdated or broken. One of the holdouts which kept me coming back to babel was JSX, but eventually I learned to love preact and its hyperscript-inspired template function. The code ends up being a bit more verbose but you drastically cut down on dependencies. Babel is still superb if you're targeting a broad range of browsers. Although during development I usually disable babel-loader from Webpack for the improved performance and debugging experience.

lxe 8y ago

Repl (https://babeljs.io/repl https://babeljs.io/repl) seems to still be on 6.26. I wish I could select the babel version on the official online repl, just like https://flow.org/try/ https://flow.org/try/

alangpierce 8y ago
In the meantime, looks like you can try out 7.0.0 here: https://babeljs.io/repl/build/7.0/ https://babeljs.io/repl/build/7.0/
- hzoo 8y ago
  thanks for posting! I personally usually just use https://babeljs.io/repl/build/master https://babeljs.io/repl/build/master!

dergachev 8y ago

Congrats Logan!

cimmanom 8y ago

Will configuration be an less esoteric?

TheAceOfHearts 8y ago

Great job to everyone involved! I've been keeping up with the project since it was 6to5, and these changes look like they'll help clean things up quite a bit and hopefully reduce user confusion. This change might a bit painful for some, but it had to happen. People shouldn't be relying on such early proposals in production. I've been using @babel/preset-env since early on and it's superb. You just pick what platforms you're going to target, and you're pretty much good to go. I'd suggest being a bit weary with automatic polyfills. It's very easy to start using every new feature out there only to have your resulting bundle balloon in size. Depending on the type of project, it might sometimes be better to be explicit about which features can be used, and manually importing those polyfills so you fully understand the price that you're paying. There will probably be some people complaining about complexity and how certain things are still confusing. Although I would agree that there's still room for improvement, targeting multiple independent platforms just seems like it's a challenging problem to solve well. My experiences with cross-compiling native apps have been fairly limited, but when I've tried it I found it far more overwhelming when compared to setting up babel. Perhaps it's just my limited experience in the native space. Am I the only one, or have others shared similar experiences? If you disagree, I'd be very interested in reading about which tools you've used, and examples of ways in which you believe babel could be simplified or improved.

tracker1 8y ago
I've been doing two targets on my most recent projects... one for ES2017+ (async support in browser), and another for legacy (IE>=9). Which wasn't too bad for some things... for one of the projects, got to be too much, and I now just do a test for async, and if it fails redirect to "/legacy.html"
- syspec 8y ago
  What browsers support generators, but do not support await? The polyfill for async, converts those calls to generator functions - however i'm not aware of any browsers which support generator functions, but DO NOT support async/await
  - 8y ago

sugarpile 8y ago

A reminder if you or your org use Babel to consider donating to Henry's patreon (https://www.patreon.com/henryzhu https://www.patreon.com/henryzhu) He's a smart, nice person who plays a large part in software that many of us use on a daily basis. Support open source if you can :)

amasad 8y ago

Really cool to see how far the project has come under Henry's stewardship. A fun story about how I got involved with the project: in Jan 2015 when I was working at Facebook on what would become React Native (was a secret project at the time), I was replacing an ad-hoc in-house built JS transformer and was building my own compiler. But then decided to give this "6to5" thing I've been hearing about a spin -- so I opened my first PR to the project: We're looking into using 6to5 [what Babel was called at the time] for a project at Facebook -- and although we make the library -- the project is stuck for some time on React v0.11 which used a different transform. https://github.com/babel/babel/pull/410 https://github.com/babel/babel/pull/410 Was so impressed by the turnaround time on that PR and the overall quality of the project that I contacted @sebmck to see if we can recruit him to work with us. He was interested and so I referred him to a recruiter. A day later she comes back to me: "did you know this is a 17-year-old kid in the middle-of-nowhere in Australia?" (I didn't). We had to wait until he was 18 before we made him an offer and he joined our team :) (eventually we got all of Facebook.com to run on Babel and not just React Native https://twitter.com/amasad/status/631251607422787584 https://twitter.com/amasad/status/631251607422787584) Like Henry mentions: working on 6.0 was hard and really controversial -- our vision for Babel was to serve as compiler infrastructure for JavaScript (which we've achieved to some extent since so many tools build on top of it and most users use it as part of a bigger toolchain like webpack) but many of our users disagreed with the direction and we were at the receiving end of much vitriol from the community (including here on HN). We're now vindicated (many times over) but goes to show how OSS maintainership can not only be a thankless job, but quite a stressful one too. Thank you Henry and the rest of the team for you dedication.

slavik81 8y ago
> We had to wait until he was 18 before we made him an offer Out of curiosity, why was that?
- augbog 8y ago
  Legal reasons to work in the US have to be 18 I think. Or something with visas
- 8y ago

tracker1 8y ago

Nice to see this... been sticking with the beta/rc for about a year now. Hopefully some of the edge cases left over (especially wrt webpack) can roll over now.

kylecordes 8y ago

Of course it is great to see this progress, this big pile of improvements in Babel. Babel plus its ecosystem support both a mountain of production code and a remarkable playground in which upcoming language ideas gradually become mainstream. But... While Babel-core isn't overwhelming, the full set of transitive dependencies you get in normal use (with "env") is a lot of code, spread across numerous packages. Many projects care about the provenance of their dependencies, and having a very large number makes such provenance more to think about, more to track down, etc. The voluminous transitive dependencies also make for a slow "npm i" and so on. I've been able to avoid Babel for some use cases: Even when not using types, the TypeScript compiler can handle a broad swath of typical ES-newish to ES-6-or-5 compilation use cases, with a total of 1 dependency (+0 transitive dependencies), quickly. The main downside of this approach is that people look at you funny when you use "tsc" on a non-TypeScript project.

hzoo 8y ago
If dependencies are an issue, I would like to make another package that just bundles it all into 1 package (reuse `babel`) so there aren't any "deps" to install but haven't gotten around to doing it, would be a useful contribution opportunity for someone though.

arenaninja 8y ago

I have been using the alpha, beta and rc so far on a project that's scheduled to go live before the end of the year, and @babel/preset-typescript has been a joy to use (minus can't use const enum) Congratulations to the @babel team, this release is hard earned

littlestymaar 8y ago

I really hope this new version is more polished than Babel 6 was at the time of its release. At my former company, the migration to Babel 6 was such a disaster we jokingly renamed it to «Babel Vista».

transfire 8y ago

It is not a COMPILER. It's a TRANSPILER. I got a bit excited for about three seconds until I read the finer print.

detaro 8y ago
Transpilers are a type of compiler.
a_humean 8y ago
People have long dropped that confusing and often times implied patronising distinction in relation to babel. Its a type of compiler. The direction of travel in terms of abstraction isn't important.

njn 8y ago

This is the most complicated upgrade guide I've ever seen: https://babeljs.io/docs/en/v7-migration https://babeljs.io/docs/en/v7-migration