Discussion on how to integrate with Babel's ability to use recast

So after https://github.com/babel/babel/pull/3561 allows babel to use recast as the parser/generator and the other prs fixed the babel 6 ast nodes for ast-types/recast we should be able to use babel as the transformer for jscodeshift.

Is there anything we want to do to the api to make it easier or should users just add it in themselves? babel-core/recast are already dependencies, but yeah it’s not necessary (Ah I see babel-core is v5 for the babel 5 parser). Maybe it’s just a docs change.

module.exports = function(fileInfo, api) {
  return api.jscodeshift(fileInfo.source)
    .findVariableDeclarators('foo')
    .renameTo('bar')
    .toSource();
}

const transform = require('babel-core').transform;
const recast = require('recast');
const plugin = require('./plugin');

module.exports = function(fileInfo, api, options) {
  return transform(fileInfo.source, {
    parserOpts: {
      parser: recast.parse
    },
    generatorOpts: {
      generator: recast.print
    },
    plugins: [plugin]
  }).code;
};

// ./plugin.js
module.exports = {
  visitor: {
    VariableDeclarator({ node }) {
      if (node.id.name === "foo") {
        node.id.name = "bar";
      }
    }
  }
};

Also interesting sidenote would be using the jscodeshift type api in babel

cc @fkling, @cpojer, @drewml

[eventualbuddha]

I’ve open-sourced what I have at https://github.com/square/babel-codemod. PRs/suggestions/comments welcome!

[benjamn]

My two cents:

The Visitor-based transformation API used by Babel tends to be better for complicated transforms, and transforms that need to be run by other people who don’t fully understand what’s happening behind the scenes, which means handling more edge cases automatically, and not giving up in cases when it’s easier to edit the code by hand.

The Collection-based API is much better for hand-supervised codemods, and for transforms where it’s ok if you don’t handle every edge case, because you know that certain patterns of syntax are rare in your specific codebase.

These may not be the only possible options in the API landscape, but they’ve proven effective in their respective niches. I don’t think it necessarily makes sense to unify them into one API, but I’m totally in favor of making both kinds of transforms easier to write, if possible.