Giters

erikras / react-redux-universal-hot-example

A starter boilerplate for a universal webapp using express, react, redux, webpack, and react-transform

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Upgrade to Babel v6

erikras opened this issue · comments

commented

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.

commented

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"
  ]
}
commented

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

commented

@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

commented

Awesome work, @justingreenberg!! 👍

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

commented

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

commented

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

commented

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

commented

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

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

commented

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

commented

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.

commented

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?

commented

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?

commented

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

commented

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?

commented

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

commented

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

commented

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

commented

@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.

commented

@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

commented

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

commented

@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

commented

@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 ❤️.

commented

@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?

commented

@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.

commented

@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!

commented

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 👍