search

lukeed / fly-esnext

Allow for ES6 and ES7 support throughout a Fly environment.
Other
12 stars 1 forks source link

Update to Babel 6 #3

Closed tjbenton closed 7 years ago

tjbenton commented 7 years ago

I've been having issues with fly-esnext when I'm using babel 6+, and my own .babelrc config because it tries to pull in babel 6 dependencies into babel 5.

I updated this package to use babel 6+ and also disabled the babelrc from getting merged. This way no user settings for babel will mess up the flyfile that's written in es6+.

I also added a very very simple test to ensure that this package is working as expected all versions of node. If you enable travis ci it will run on the same versions of node as the flyjs package does. Here are the passing tests https://travis-ci.org/tjbenton/fly-esnext/builds/161449482

lukeed commented 7 years ago

We're using Babel 5 on purpose. Babel 6 is split into sub-modules, and these aren't referenced correctly when fly-esnext is required by fly.

require('babel-5') 
//=> has everything it needs already, interally

require('babel-6')
//=> traverse node_mods & require sub-mods

// fly-esnext
require('babel/register')

// fly
require('fly-esnext')
//=> require('babel')
//===> v5: ends here, no extra requires
//===> v6: require 30+ more modules; context is lost. aka, loses track of where to look
lukeed commented 7 years ago

So, while the Travis tests may work for this repo specifically, that doesn't translate to a working fly export.

Babel6 is unusable (for this repo) because the setup you're requesting (and the way it was originally) doesn't support all Node versions. Node 5.x is the dividing line. I can't remember which side of the line allows this to work & which doesn't; but either way, it means that half of Fly's users will not be able to use fly-esnext if it's based on Babel6. @tjbenton

tjbenton commented 7 years ago

I have had to use my own version of fly-esnext for the last 3 projects I've worked on because the one on npm was breaking my build. I've tried using babel 6 on 0.12+, because I'm using in on a project that requires it to work on 0.12 and above so I know it works across all of the different version of node and iojs. I would just like to not have to reference my github version for the build tools.

I've added a more real world test case to the repo so that it has to be installed like you mentioned above. So that fly is referencing it exactly how it would when it's installed on a project.

Here are the passing test for every version of node https://travis-ci.org/tjbenton/fly-esnext/builds/161714772. I'm currently using my personal tjbenton/fly-esnext repo on 3 projects and haven't come across a single problem across multiple versions of node. The reason why there was probably a problem before was the babelrc option was not disabled so it was conflicting with what ever the users babel config was. On babel 5 I don't think you can disable this option.

lukeed commented 7 years ago

I'm sorry, but I don't think I'm being clear on the issue. Your local intra-repository tests can't emulate what actually happens in the deep-nesting web of node symlinks.

I've made a test repo. Use (and install) it with Node 0.12 or anything less 4.5 --- I tested 4.2.2 and 0.12.

As long as Fly supports 0.12 & 4.x, we cannot upgrade fly-esnext to Babel 6. When Fly drops support for these versions, this upgrade will happen. In the meantime you'll have to continue using your own branch because it's specific to your environments.

lukeed commented 7 years ago

@tjbenton Do you see what I mean now?

tjbenton commented 7 years ago

I do but I find it strange that the travis ci tests past if it error like this on those versions.

tjbenton commented 7 years ago

I got my projects working with the old babel 5 version but not until I my babel config my package.json, and in another project the .babelrc so this is why I thought it was broken. As soon as I moved my babel config into my flyfile.js to use with fly-babel it was able to work as expected. The babel register (v5) in this package was using my babel config and it was trying to import babel 6 plugins so that's why it was failing for me.

lukeed commented 7 years ago

It errors because your tests don't (and can't) simulate the deeper level of symlinks that happen at runtime.

There may be a way to turn off babelrc parsing on babel5, but I'm not sure.

Glad you got your projects working with 5