Transition to using Babel 6

[joshblack]

Just wanted to say I love this project! Thank you so much to all the contributor's for their work on this.

After getting used to using jscodeshift inside of http://astexplorer.net, one of the problems I ran into when going to use this on my own machine was the absence of support for Babel 6. Was just curious if there were any plans for supporting Babel 6 in the near future, or if any kind of work has been done already on this front.

[hzoo]

This would require a change to recast/ast-types benjamn/ast-types#132 right?

[joshblack]

Yeah, and I believe a change in how recast accepts its parser option, as Babel 6 now exposes the babylon project which doesn't read options from a .babelrc file, if I'm reading the source correctly.

[fkling]

Using babel6 primarily depends on support from recast / ast-types, yes. However, it may not be as simple as adding new types, depending on how far babel6/babylon will diverge from the ESTree spec.

That said, it's probably possible to ditch recast completely and directly use babel6 for traversal and other mutations.

No work has been done in this direction, ideas / opinions / help are welcome :)

[joshblack]

Sounds like fun, have any suggestions for where to start figuring out how this integration might work?

[hzoo]

I added the transforms for babel 6 in babel-eslint (beta) https://github.com/babel/acorn-to-esprima/blob/744f2a986d31700d8e9f24fd5487fb71ab6ca9e0/src/toAST.js#L56-L153 - there are some bugs to fix though and it can be a pain to do so (not fun 😄)

[benjamn]

Adding babylon's non-standard AST types to ast-types should be much more straightforward than abandoning ast-types or recast. The ast-types definition format is general enough to support any sort of AST, not just JavaScript, and certainly not just ~Esprima.

There's already a file for Babel-specific types: https://github.com/benjamn/ast-types/blob/master/def/babel.js

Happy to help.

[fkling]

@benjamn Sure! I was more concerned with things that may impact other parts, like scope evaluation (e.g. if Babel adds new types around Identifier that distinguish between bar and foo.bar). I guess that's not the case yet, but just something to keep in mind.

[hzoo]

@fkling There's nothing like that as far as I understand

[udnisap]

this is a cool idea. If jscodeshift can use multiple parsers it will essentially be http://astexplorer.net and will be able to migrate legacy code better. I can support with some development on this.

[EvHaus]

Just wanted to add a note for those Googling. Currently, trying to run jscodeshift with Babel 6 returns this error:

/usr/local/lib/node_modules/jscodeshift/node_modules/babel-core/lib/transformation/file/options/option-manager.js:126
      if (!option) this.log.error("Unknown option: " + alias + "." + key, ReferenceError);
                           ^

TypeError: Cannot read property 'error' of undefined
    at OptionManager.mergeOptions (/usr/local/lib/node_modules/jscodeshift/node_modules/babel-core/lib/transformation/file/options/option-manager.js:126:28)
    at OptionManager.addConfig (/usr/local/lib/node_modules/jscodeshift/node_modules/babel-core/lib/transformation/file/options/option-manager.js:107:10)
    at OptionManager.findConfigs (/usr/local/lib/node_modules/jscodeshift/node_modules/babel-core/lib/transformation/file/options/option-manager.js:168:35)
    at OptionManager.init (/usr/local/lib/node_modules/jscodeshift/node_modules/babel-core/lib/transformation/file/options/option-manager.js:229:12)
    at compile (/usr/local/lib/node_modules/jscodeshift/node_modules/babel-core/lib/api/register/node.js:117:22)
    at normalLoader (/usr/local/lib/node_modules/jscodeshift/node_modules/babel-core/lib/api/register/node.js:199:14)
    at Object.require.extensions.(anonymous function) [as .js] (/usr/local/lib/node_modules/jscodeshift/node_modules/babel-core/lib/api/register/node.js:216:7)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:366:17)

[fkling]

@globexdesigns: Did you really install the development version of jscodeshift and upgraded jscodeshift's dependency from Babel v5 to Babel v6, or is that some other strange error that happens when using jscodeshift alongside Babel v6?

[EvHaus]

@fkling This was a result of using jscodeshift (installed globally) on a code base that uses Babel 6. I did NOT install jscodeshift's development version or do any manual upgrades.

[fkling]

@globexdesigns: This seems to be a different problem and has nothing to do with the topic discussed here. This topic is about upgrading jscodeshift's internal / ownl version of Babel to v6.

jscodeshift shouldn't care whether the files it transforms happen to be converted with Babel or not, that's complete irrelevant. However, there might be an issue with jscodeshift's Babel version picking up the .babelrc file of the project. If that's the case, please open a new issue with more information to reproduce the problem.

[kjanoudi]

@fkling I can confirm that the issue @globexdesigns identified was indeed jscodeshift picking up the project's .babelrc. I will open an issue for that now.

[jamestalmage]

I would prefer fixing recast/ast-types to make this work. I think ast-types provides a better generalized type system than babel-types does.

I am toying with auto-generating a babel-6 definition for ast-types by simply recursing the values exported by babel-types, similar to how the babel-types docs are generated.

It's currently blocked awaiting benjamn/ast-types#145 or other similar solution to benjamn/ast-types#57 .

Sample output:

...

        def("ArrayExpression")
                .bases("Expression")
                .build("elements");

        def("AssignmentExpression")
                .bases("Expression")
                .build("operator", "left", "right")
                .field("operator", String)
                .field("left", def("LVal"))
                .field("right", def("Expression"));

...

[fkling]

This should be implemented now with #119.