为啥套娃？聊聊 babel、jscodeshift 和阿里妈妈的 gogocode

首先，我是《babel 插件通关秘籍》 掘金小册的作者，对 babel 有源码级的掌握，算是有资格讨论这个话题。

本来会探讨以下话题：

• babel 是怎么转换代码的
• jscodeshift 是怎么转换代码的
• babel 和 jscodeshift 的区别
• 为什么不推荐 gogocode

babel 是怎么转换代码的

babel 编译流程分为 3 步： parse、transform、generate

• parse：把源码转成 AST，babel parser（babylon） 支持 esnext 语法，可通过插件支持 typescript、jsx、flow 等语法
• transform：对 AST 进行转换，通过 visitor 对不同的 AST 进行处理
• generate：打印转换后的 AST 为目标代码，并生成 sourcemap

转换插件这样写（小册中的一个 linter 的案例）：

const { declare } = require('@babel/helper-plugin-utils');

const noFuncAssignLint = declare((api, options, dirname) => {
    api.assertVersion(7);

    return {
        pre(file) {
            file.set('errors', []);
        },
        visitor: {
            AssignmentExpression(path, state) {
                const errors = state.file.get('errors');
                const assignTarget = path.get('left').toString()
                const binding = path.scope.getBinding(assignTarget);
                if (binding) {
                    if (binding.path.isFunctionDeclaration() || binding.path.isFunctionExpression()) {
                        const tmp = Error.stackTraceLimit;
                        Error.stackTraceLimit = 0;
                        errors.push(path.buildCodeFrameError('can not reassign to function', Error));
                        Error.stackTraceLimit = tmp;
                    }
                }
            }
        },
        post(file) {
            console.log(file.get('errors'));
        }
    }
});

module.exports = noFuncAssignLint;

声明 visitor 函数，然后在遍历的过程中会被调用，其中可以拿到 path 和 state 的 api：

path 是节点之间的关系，每个 path关联父节点和当前节点，path 对象构成一条从当前节点到根结点的路径。state 是遍历过程中的共享数据的机制。

通过 path 的一系列增删改查 AST 的 api 来完成 transform。

比如下列 api：

getSibling(key) 
getNextSibling()
getPrevSibling()
getAllPrevSiblings()
getAllNextSiblings()
isXxx(opts)
assertXxx(opts)

insertBefore(nodes)
insertAfter(nodes)
replaceWith(replacement)
replaceWithMultiple(nodes)
replaceWithSourceString(replacement)
remove()

jscodeshift 是怎么转换代码的

jscodeshift 也是代码转换的工具，但是 api 风格不同，是主动查找 AST，然后修改成新的 AST，最后生成代码的形式：

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

jscodeshift 的优势是更简洁。

但是 jscodeshift 能代替 babel 么？ 可以看下大牛给出的答案：

babel 和 jscodeshift 的不同

jscodeshift 的 parser 是 recast，曾经有 babel 的维护者想结合这两者：

github.com/facebook/js…

利用 recast 做 parse，然后基于 babel parser 做转换。

下面有一个很精彩的回复，明确了 babel 和 jscodeshift 的不同：

我来梳理一下：

babel 的 transform api 是visitor 风格，也就是声明对什么 ast 做什么处理，然后在遍历过程中被调用，这种不和具体遍历方式耦合的写法是一种设计模式（访问者模式），处理再复杂的场景也能应对。就是处理简单场景显得稍微啰嗦点。

jscodeshift 是 collection 风格，类似 jquery，主动查找 ast，放到集合中操作，适合处理简单场景，要知道每种 ast 是怎么查找到的，然后做转换，要处理很多很多 case，万一查找路径不对，那可能就漏掉了一些情况，比起 babel 来，很难在复杂场景下没有 bug。

就像 jquery 和 mvvm 的区别一样，复杂场景还是 mvvm 的方式（babel）靠谱，不会漏掉一些 dom 没处理。（只是一个类比）

所以，简单场景可以用 jscodeshift，而所有场景都可以用 babel。

babel 的 visitor 的优点就是设计模式中访问者模式的优点，不和具体遍历方式耦合易于复用。

为什么不推荐 gogocode

gogocode 是这两天阿里妈妈出的 ast 修改工具，基于 babel 做了一层封装，说是简化了 ast 操作。

api 类似这样：

$(code)
  .find('var a = 1')
  .attr('declarations.0.id.name', 'c')
  .root()
  .generate();

没错，基于 babel 的 visitor 风格的 api 封装出了 jscodeshift 的 collection 风格的 api。

本来 babel 的 visitor 虽然写起来麻烦一些，但是所有路径都能够处理到，而改成 collection 风格之后，一旦落掉了某条路径没错里，就会 bug。处理的 case 特别多，不适合复杂场景。

babel 本来的 visitor 模式是一种优点，结果又在上层封装出了 collection api。。如果想这么封装，为啥不直接基于 jscodeshift 呢。。。我没看懂这波操作。

我不看好这个 babel 套娃，我没有自信保证复杂场景下能够处理所有路径而不遗漏 case，复杂场景我选择直接用 babel 的 api。

总结

babel 是访问者设计模式的实现，分离了遍历方式和对 AST 的操作，使得操作可以复用，jscodeshift 是 collection 风格，类似 jquery，复杂场景容易落掉 case。

gogocode 基于babel 实现了 collection 风格，不看好，容易落下 case。

一句话总结： 简单场景可以用 jscodeshift，所有场景都可以用 babel，不怎么推荐 gogocode。

最后打波广告，想学 babel 的可以看我的小册《babel 插件通关秘籍》，手写babel 的案例代码已经 push，小册马上更新。