Upgrade to Babel v6

Question

Upgrade to Babel v6

erikras opened this issue 9 years ago · 29 comments

Anyone want to give this a shot? Quite a few things have changed. I don't really understand how the react-transform stuff is set up in the .babelrc. I got most of the way there, but had to turn back.

Kudos for anyone who can figure this out.

Answer 1 · 2015-11-02T21:23:25.000Z

Word of advice, apparently you have to put some plugins inside your presets array, like so:

{
  "presets": [
    {
      "plugins": [
        "syntax-class-properties",
        "transform-class-properties"
      ]
    },
    "es2015",
    "react",
    "stage-0"
  ]
}

Answer 2 · 2015-11-02T21:56:31.000Z

From discussion of this Babel 6 official post
plugins array is not inside the presets:

    {
       "presets": [ 
            "react", 
            "es2015" 
        ],
       "plugins": [ 
            "transform-es2015-modules-commonjs", 
            "transform-react-constant-elements" 
        ]
     }

Hope that helps

Answer 3 · 2015-11-03T01:11:16.000Z

@erikras we'll have to wait for some dependency updates to support babel 6 (react-transform, typecheck and eslint)... in the meantime, our new .babelrc will look something like this:

{
  "presets": ["es2015", "react", "stage-0"],
  "plugins": [
    "typecheck"
  ],
  "env": {
    "development": {
      "plugins": [
        ["react-transform", {
          "transforms": [{
            "transform": "react-transform-hmr",
            "imports": ["react"],
            "locals": ["module"]
          }, {
            "transform": "react-transform-catch-errors",
            "imports": ["react", "redbox-react"]
          }]
        }]
      ]
    }
  }
}

a couple of notes :

presets can be passed as query to babel-loader (webpack dev config)
optional and stage objects have been removed from babel-loader query
babel-core/polyfill is now babel-polyfill

i'm happy to take care of this once deps are supported

Answer 4 · 2015-11-03T07:49:18.000Z

Awesome work, @justingreenberg!! 👍

If anyone comes across this issue after the next react-transform release, leave a note to remind us.

Answer 5 · 2015-11-03T10:34:04.000Z

Babel Doctor was just released. Might be helpful to this issue.

Answer 6 · 2015-11-03T19:59:17.000Z

I did this yesterday on another project of mine. It took a couple hours.

Babel no longer takes options. You need to specify everything in .babelrc:
https://github.com/austinmao/sails-mongoose-boilerplate/blob/front-end/.babelrc

You have to require polyfill if you are using regenerator (async/await)
https://github.com/austinmao/sails-mongoose-boilerplate/blob/front-end/test/bootstrap.test.js

babel has been replaced with babel-core

Answer 7 · 2015-11-03T22:00:46.000Z

When we do upgrade to Babel 6, let's try and lump it into one nice commit so everyone can migrate easily!

Answer 8 · 2015-11-18T03:10:11.000Z

Babel 6 Migration (Updated 12/09/15):

babel-plugin-transform-decorators - decorators are not supported in babel 6... if this becomes a bottleneck we can switch to function composition until the specification/proposal is stable
- Edit 12/09/15: Implement new decorator proposal when finalized
babel-plugin-react-transform - supported 12/08/15
babel-eslint - supported 11/28/15
babel-plugin-typecheck - supported 11/17/15

so yeah, bleeding edge is all fun and games until your toolkit completely changes

Answer 9 · 2015-11-18T14:46:51.000Z

"Bleeding edge is all fun and games". LOL. 🔪 🏥 💉

Answer 10 · 2015-11-18T14:49:12.000Z

to be honest I would mark this repository as stable before going to babel 6.
Afterwards we can mark it as stable again if all those issues are resolved.

Answer 11 · 2015-11-18T18:32:26.000Z

I was thinking the same thing. However, with thoughts to "stable", React itself is still not 1.0, but Redux and React-Router are. Should we continue as pre-1.0 or not?

Answer 12 · 2015-11-18T18:32:32.000Z

@erikras ^

Answer 13 · 2015-11-18T20:07:02.000Z

You could probably edit the comment and still manage to tag me. In fact, I'm gonna try that with this comment. [Edit: @quicksnap] 😃

It's a shame that even Facebook fails to follow SemVer.

I'm confused as to what this "stable" labeling actually means. Do you just mean declaring 1.0?

Answer 14 · 2015-11-27T09:38:10.000Z

Just a couple more days..
gaearon/babel-plugin-react-transform#50

Answer 15 · 2015-12-10T04:19:48.000Z

Seems gaearon/babel-plugin-react-transform#50 has been merged. Any updates on this front?

Answer 16 · 2015-12-10T06:29:34.000Z

babel-plugin-transform-decorators - decorators are not supported in babel 6... if this becomes a bottleneck we can switch to function composition until the specification/proposal is stable

@erikras are you ok with removing decorators?

Answer 17 · 2015-12-10T06:55:01.000Z

@justingreenberg https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-decorators is not enough?

Answer 18 · 2015-12-10T07:49:30.000Z

currently no, follow Line 83: "Decorators are not supported yet in 6.x pending proposal update."

however, it looks like things have changed since my last update:

Hey everyone, I just want to say that we're well aware of how much of a pain the lack of decorators in 6.x has been. Unfortunately, things have taken a bit longer than originally hoped. Rather than try to have Babel 6 support both decorator proposals, the intention is still for Babel 6 to implement the new proposal once it has been officially presented to TC39. -- Thu, Dec 3, 2015

TL;DR; support is coming, at some point, and they were thinking about it as recently as a week ago

which is encouraging. however, if you take the time to read the thread above, there are going to be a few gotchas, and having been involved in the initial effort to convert the initial react-transform plugin, i can say from experience—transpilation is dirty work... @erikras up to you dude

Answer 19 · 2015-12-10T19:59:06.000Z

How about using the following plugin until babel implements the new decorator proposal:
https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy

Mentioned here:

That said, your comments have definitely been heard, so I've put together a plugin that does its best to implement Babel 5 style decorators in Babel 6: https://www.npmjs.com/package/babel-plugin-transform-decorators-legacy

Answer 20 · 2015-12-10T20:05:00.000Z

My vote would be to wait until the dust on decorators settles.

Answer 21 · 2015-12-10T20:38:17.000Z

@quicksnap agreed—or replace with higher order functions until there's supported in stage-0

at the end of the day it's just a fantasy until the proposal gets through TC39. i'm still traumatized from losing my beloved ::bind operator.

i'm all for using experimental features, but we should still make an effort to keep ES as idiomatic as possible—let's not delude ourselves. using babel to transform code to a target that doesn't really exist just feels like the wrong way to be using it.

Answer 22 · 2015-12-10T21:13:08.000Z

@lndb that is a very experimental implementation—if you read the full thread there are a bunch of issues, including conflicts with class property transforms. it looks like a massive headache to support what is essentially just syntactic sugar. if decorator support is critical, we should just hold off on babel 6 for now

Answer 23 · 2015-12-16T23:10:17.000Z

@quicksnap , @erikras Any updates on this?..

Answer 24 · 2015-12-16T23:59:20.000Z

@sars for update see: https://phabricator.babeljs.io/T2645 the legacy plugin mentioned by @lndb babel-plugin-transform-decorators-legacy was updated yesterday by a core contributor and should provide the same functionality with babel 6, most of the issues appear to have been resolved. i have not tested it yet, but if it works i could probably take care of migration over the weekend

Answer 25 · 2015-12-30T19:06:31.000Z

@justingreenberg Did you get a chance to play with the legacy update? Were things smooth? Any hope for 6.0 within the next week or so?

I was about to blindly dive into upgrading to 6.0 just now - this thread saved me ❤️.

Answer 26 · 2016-01-09T16:33:53.000Z

@justingreenberg Why do we need such decorators at all? where do we use them? May be it make sense to avoid using them so far, if there are not lots of places in the code, where we use them?

Answer 27 · 2016-01-12T16:10:55.000Z

@sars i agree and prefer composability personally, but decorators are used extensively in this project and many developers seem reluctant to give them up... we are even chaining them ie:

/// containers/app.js
@connectData(fetchData)
@connect(state => ({user: state.auth.user}), {logout, pushState}))

@isTravis i'm sorry i have been so swamped with real life that i may not get around to this for another week or two. i totally know how important it is to get this updated to babel 6—i haven't forgotten about it!

i will attempt migration with legacy decorators so existing code can be left as-is.

some of the more advanced usage may break the transform, in which case i'll refactor the edge cases to use functional composition for now, if @erikras @quicksnap are cool with that. due to the advanced syntax and deep babel integration in this project, a sloppy migration will result in mysterious bugs that are virtually impossible to identify without a deep understanding of the toolchain and build pipeline. i need to spend an afternoon to bring myself up to speed on the codebase and carefully implement the update.

Answer 28 · 2016-01-12T16:24:25.000Z

@justingreenberg No problem! I'm actually all set with the upgrade. I followed #778 and things were smooth for me! I don't use decorators much in my code - so that wasn't an issue for me.

Thank you for following up!

Answer 29 · 2016-01-12T16:31:13.000Z

no worries—i hadn't even seen that pr, obviously i need to get back up to speed. #778 looks good at a glance, i'm glad it worked for you! without decorators the update is pretty straightforward 👍