Update to babel 6

[geowarin]

This is a WIP for #12.
Currently, there is a bit of duplication on the babel presets used for the different builds, we can definitely do something smarter.

I chose to use the following presets for babel:

• es2015
• react
• stage-2 (mainly for the spread syntax)

[geowarin]

The travis build is broken with npm 2 (you should probably clear the cache) but it works on my machine (tm)
With npm 3, the assertions on the node modules present after nwb new failed because of the flat package structure.

For some reason, karma no longer likes being run in /tmp so I had to change that.

[insin]

What does the use case of setting your own babel stage and enabling loose mode look like with Babel 6? i really liked how simple this was with Babel 5 since all the transforms were included, but I suspect we could support the same configuration UI with more work behind the scenes.

[geowarin]

Hi @insin.
You are right, the user config part was totally left out by this PR.
I rebased and modified the getUserConfig function so it works with babel 6.

Essentially, the stage is now a preset and not a babel property so we have to extract it out of the user config. Cool side-effect: selecting a babel stage with nwb becomes simpler than with vanilla babel 😄

I amended the tests for them to reflect a real usage with babel 6.
Tell me what you think.

[geowarin]

Please clear the travis cache to make the build pass!

[cafreeman]

@geowarin Is this still blocked by the travis cache or is there a larger overriding issue? Just ran into the limitations of babel 5 and came looking for this exact issue

[geowarin]

Hi @cafreeman! This PR was a work in progress.
It needs rebasing, I haven't taken care of it for months!
I guess @insin is keeping it around for the future.

[insin]

@cafreeman Could you add the issues you're having to #12?

I'm using nwb in projects at work which use vanilla Node.js 4 LTS, which comes with npm2. I don't currently need to upgrade to Babel 6 and I'm not willing to make install time, size and performance unacceptable with npm2 in order to do so.

[joshwcomeau]

Just my two cents, but I think babel 5 is a better choice for now. Babel 6 has issues with decorators.

[cafreeman]

@insin My issues actually were related to presets, but I ended up figuring out how to tweak the nwb.config file to configure babel 5 appropriately and now everything works great.

[tomchentw]

I'd love to see nwb adapt babel@6. Since there are many major packages that only supports babel@6, e.g. babel-plugin-lodash, and babel@6 also provides better interfaces for plugins as well. Let me know if there's anything I can help to make this happen.

[insin]

@tomchentw do you know if anyone has made alternative babel@6 preset modules which provide presets in an npm2-friendly manner?

I was wondering if it would be feasible to have one module which depends on every single plugin, offers a bunch of entry points for the different presets, and includes all the plugin module dependencies in its own dependencies so they don't get duplicated underneath it. Would be interesting if it could also handle a loose mode entry point for each preset, so current nwb stage and loose config could be as simple as it currently is.

If that's now possible, I'd rather have nwb make a clean, explicit break from npm2 than offer terrible installation time, size and performance.

[tomchentw]

@insin FYI, today's news, you may want to try out babel@^6.8.0 since it seems to reduce lots of dependencies.

https://github.com/babel/babel/releases/tag/v6.8.0

[insin]

That looks like good news :)

My approach to avoiding that was potentially going to be creating a new package which depends on all the babel plugins, uses its own package.json to manually deduplicate where possible and gives you entry points for using them using Babel 5-style stage numbers and also entry points equivalent to using loose: 'all'.

I may still do this as we need to manage that somewhere anyway.

[insin]

On second reading, it seems this bug gave npm3 users the npm2 experience w.r.t. babel-runtime when this particular dependency scenario occurred, so it won't improve things with npm2.

This PR looks like it handles the way I want to use loose config for plugins, linking it here for later reference: babel/babel#3331

[slmgc]

@insin not sure if update to babel 6 is a great idea ATM because it has an issue with parent constructor calls in IE < 11, check it out: https://phabricator.babeljs.io/T3041

[insin]

Thanks for the PR @geowarin, it was really handy when getting started with the Babel 6 work, but there ended up being way more I discovered I wanted to do and it turned into a massive commit in the end.