如何使用jscodeshift来自动修改公开的API接口

如何使用jscodeshift来自动修改公开的API接口

从一个简单场景出发

在代码实现中，这个加载中状态被定义为了名为isInLoadingStatus公开prop。用户可以通过设置其值来控制Button的状态：

一个实习生在某一天code review的时候提出了一个问题：在组件库中的其他地方，所有的boolean状态都是用一个单词来表示的，比如checked, disabled等。如果按照这个惯例，这里应该把isInLoadingStatus简化为loading。好主意！

import Button from '@fancylib/button';const app = () => (Click me)

复杂情况

比如用户对其做了二次包装以适配更符合自己用户的使用习惯，这使得简单的全局字符串替换变成了不可能:：

除了这些问题之外，由于这是一个非常受欢迎的组件库，Button在很多（包括内部和外部的）产品中都有使用，你没有办法访问所有的用户代码，更没有办法让所有人都用手工的查找替换来做更新，你需要另寻出路。

使用jscodeshift

jscodeshift就是这样一个工具（工具集）。简单来说，jscodeshift的工作方式就是将源代码分析成一棵树（抽象语法树），然后提供API来修改这棵树，最后再把树生成为代码。

也就是说，她可以读懂你的代码，并提供指令（API）来根据你的意愿修改相应的代码。

实现

接下来，我们可以通过实现一个可以完成上述场景的自动重构的脚本来对jscodeshift的使用做一个简单介绍。简单来说，jscodeshift的工作流程是：首先你需要定义一个转换脚本（transform），这个脚本需要符合一定的规范以便jscodeshift调用；然后jscodeshift的命令行工具会启动runner，并将转换脚本应用到某个文件或者某个文件夹中的所有文件中：jscodeshift -t myTransform src

定义一个transform

也就是说，我们所有的逻辑都会定义在转换脚本中。transform脚本需要导出一个固定格式的函数：

在详细讨论如何使用jscodeshift的API来修改代码之前，我们来略微看一下抽象语法树的概念。这将是我们脚本需要操作的主要对象。

抽象语法树AST

举个例子，我们的代码片段：

import Button from '@fancylib/button';const app = () => (Click me)

有了这些基本概念之后，我们就可以开始编写一个简单的transform了。这里我们可以通过AST Explorer提供的在线IDE中的Transform功能来实时调试（此处选择jscodeshift作为转换器）。

然后我们定义这样一个转换函数：

// Press ctrl+space for code completionexport default function transformer(file, api) { const j = api.jscodeshift; return j(file.source) .find(j.JSXIdentifier) .forEach(path => { if(path.node.name === "isInLoadingStatus") { j(path).replaceWith( j.identifier('loading') ) } }) .toSource();}

当然了，作为一个严肃的程序员，我们不应该通过一个在线IDE来进行开发。幸运的是jscodeshift可以和jest完美配合，同时我发现编写自动化脚本是一个非常适合测试驱动开发的场景：

输入输出都非常明确 各种不同的边界场景很容易想象/编写成用例 每一个步骤都可以划分的比较小

jscodeshift提供了一个小工具defineInlineTest，通过它你可以很方便的定义测试用例：

import { defineInlineTest } from 'jscodeshift/dist/testUtils';import transformer from './transformer';describe('transformer', () => { defineInlineTest( { default: transformer, parser: 'tsx' }, {}, ` import Button from '@fancylib/button'; export default () => (Click me ); `, ` import Button from '@fancylib/button'; export default () => (Click me ); `, 'change isInLoadingStatus to loading' );});

当然，如果你不习惯字符串模板的话，它同时还提供了基于文件形式的测试定义，这样你可以将测试的输入（转化前）和输出（转化后）外置到文件中，并在其中构建较为复杂的使用场景。

比如我们希望这个transform不要误伤我们代码中使用的其他Button，比如我们使用了另外一个组件库，而巧合的是那个库中Button也有一个isInLoadingStatus。

那么对应的测试用例会是：

defineInlineTest( { default: transformer, parser: 'tsx' }, {}, ` import Button from '@facebook/button'; export default () => (Click me ); `, ` import Button from '@facebook/button'; export default () => (Click me ); `, 'should not change isInLoadingStatus to loading from other package' );

对应的我们需要在代码中加入相应的逻辑：

// Press ctrl+space for code completionexport default function transformer(file, api) { const j = api.jscodeshift; const root = j(file.source); const specifiers = root .find(j.ImportDeclaration) .filter((path) => path.node.source.value === "@fancylib/button") .find(j.ImportDefaultSpecifier); if (specifiers.length === 0) { return; } //...}

即，我们先查找所有的import语句，如果没有找到从@fancylib/button导入的Button就跳过后续的操作。你应该已经注意到了，我们这里又很多的诸如j.ImportDeclaration和j.ImportDefaultSpecifier之类的Token定义，你可以从AST Explorer的树结构中找到类似的名称，然后用jscodeshift的API来查找并访问改节点。

这个过程或多或少有点像我们通过DOM的API来选择HTML节点一样：

document.querySelectorAll('a') .filter(anchor => anchor.classList.includes('button')) .forEach(anchor => anchor.style["text-decoration"] = "underline")

如果你觉得这里要素太多，这是很正常的。尝试着多写几个就会发现规律。

可能的陷阱

使用脚本来自动化重构的想法当然非常有诱惑了，特别是对于疲于为已经公布的API打补丁的人们来说，简直太过于美好。不过公平起见，我还是得略微说一些它的一些drawbacks。

首先，jscodeshift 的API略显晦涩，有一定的学习成本。开发过程中可能会有很多调试的工作。其次，它并不定覆盖100%的使用场景，比如对于复杂的spreading操作，需要调试和分析的工作量不容小觑，也就是说你仍然需要人工校对一些edge cases。最后，需要一些脚本来支持组件的消费团队使用，比如自动化补丁工具等，如果有多个transform，如何一次patch等问题。

小结

在这篇文章中，我们从一个简化了的实际例子出发，描述了为何jscodeshift在某些场景下可以提供的帮助，比如降低大型修改可能带来的影响（而如果影响不可避免，那么如何使其变得不那么痛苦）。随后我们描述了jscodeshift中的一些基本概念和基本的工作方式，并结合之前讨论的例子实现了部分的自动化重构。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。