Flipping this back to "In Progress", as there appears to be some issues related to babel-runtime which I'm not able to reproduce locally, but are causing test failures in CircleCI. Adding babel-runtime as a dependency results in a different error which looks very similar to the one reported here:

https://phabricator.babeljs.io/T6644

Will plan to take a closer look soon, or wait until a proper resolution is put in place in Babel if it indeed turns out to be an issue there.

The differences between what I was seeing locally compared to CircleCI appear to be due to the fact that I was running a more recent version of node / npm. In which case, upgrading our Node dependency in #1204 could be a solution, though I'll see if there's another interim option.

I've rebased and the tests now run, probably due to Node 4 in #1204 (though we're still on npm 2.x).

However, the tests still fail consistently, due to a few slow test suites. I'm unsure yet whether this is an issue with the tests themselves (FeedStore and FeedPostList), or if Babel 6 is actually slower than Babel 5, causing the tests to fall over the timeout.

/cc @blowery

hmmmm. locally:

FeedStore
    ✓ should have a dispatch token
    ✓ should not contain an unknown feed ID
    ✓ should create a pending record when sent REFRESH
    ✓ should pass through the pending state and prevent double fetches
    ✓ should accept a good response
    ✓ should accept an error


  6 passing (664ms)



  FeedPostList
    ✓ should require an id, a fetcher, a keyMaker
    A valid instance
      ✓ should receive a page
      ✓ should receive updates
      ✓ should treat each set of updates as definitive
    Selected index
      ✓ should initially have nothing selected
      ✓ should select the next item
      ✓ should select the next valid post
      ✓ should be able to select a gap
      ✓ should select the prev item
      ✓ should select the prev valid post
    Filter followed x-posts
      ✓ rolls up x-posts and matching x-comments
      ✓ when following origin site, filters followed x-posts, but leaves comment notices
      ✓ updates sites x-posted to
      ✓ filters xposts with no metadata
      ✓ filters xposts with missing xpost metadata


  15 passing (938ms)

though i'm on npm 3.something...

I've seen at least one report claiming that Babel can be significantly slower when used with npm 2 than with npm 3. Not obvious to me why this would be the case (related to flattened directly structure?):

https://news.ycombinator.com/item?id=10475713

I'll plan to do some more testing early next week.

este/este@b04f951 might help

though if we do that, we should force the docker build to use npm3 too

este/este@b04f951 might help

Definitely worth testing to see if it helps. I'll commit shortly.

rebased this on current master, fixed the conflicts, added the npm3 to see.

if npm3 doesn't fix it, we can back it out pretty easily.

Just a quick data point: building make build-wpcalypso takes 40s on both babel 5 (40.2s) and babel 6 (40.4s).

Looks good @aduth - what obstacles remain before merging this?

what obstacles remain before merging this?

The only obstacle was holiday time 😄 I'll respond to your comments shortly.

Pushed a rebase to resolve merge conflicts. Expected that tests will continue to fail however, pending remaining rewire dependencies to be removed (#5810, #5809 #5811).

Remaining on Babel 5 is becoming a bit more painful over time, as plugins we'd like to adopt or create are only available on Babel 6. For example:

• babel-plugin-transform-react-remove-prop-types to remove propTypes from production builds
• Pending changes to state selectors to import from single file import { getSelectedSiteId } from 'state/selectors'; could be optimized with a Babel plugin to avoid unnecessary importing without need for tree shaking from Webpack 2 (gist)

I merged and deployed all rewire related PRs. Great work on that one @aduth :)
I removed no longer used rewire dependency and regenerated shrinkwrap config again. I had also to resolve two more issues related to Babel upgrade and unit tests. It looks like unit tests are all green now 🎉 🎈
It looks like the tests are a bit slower with the latests Babel version, but I wouldn't consider it as a blocker.
I also checked couple of pages and they work as before.

👍 I tested this against a local docker 🐋 image. No visible changes to Calypso.

@aduth were there any other blockers on this one? The branch needs a rebase, but I think it's really close.

@gwwar Yeah, it's essentially mergeable. Performance hit is really unfortunate but I don't think we'll be able to stick to Babel 5 long-term, so the hit is inevitable.

The only other thing I wanted to check to see was whether there is any impact consideration for other projects that depend on Calypso, such as the desktop app.

Rebased to resolve merge conflicts. Also made the following changes:

• Changed stage-1 preset to stage-2
  • Separately includes transform-class-properties (ES Class Fields & Static Properties) and transform-export-extensions (export ns from, export default from) plugins
  • Leaves out decorators and class constructor calls from stage 1 (reference), which are not currently used
• Dropped babel-preset-react in favor of granular plugins
  • Using syntax-jsx, transform-react-jsx, and transform-react-display-name plugins
  • Not using syntax-flow nor transform-flow-strip-types plugins

Hope with these changes is (a) limit the number of dependencies, (b) potentially gain some performance boost (though in my anecdotal experience there is no noticeable difference) and (c) avert temptation to use stage 1 features or Flow types.