构建用于重写默认导出的 Codemod 工具

最近在工作中，我们决定迁移到命名导出/导入并添加 eslint 规则 no-default-export。

动机听起来是这样的：

默认导出会使代码更难维护，尤其是在大型代码库中。对于同一实体，导入的名称可能不同，影响代码读取过程和编写静态分析器，增加难度。相反，切换到命名导出可以消除默认导出的所有缺点。

当然，我们有庞大的代码库，手动替换 ~1500 个默认导出和 ~12000 个默认导入并不是一项有趣的工作？

主要困难是使用为命名导出创建的相同新标识符更新所有链接文件。

我给你举个例子：

// Button/Button.tsx
const Button = () => {};
export default Button;

// Button/index.ts
export { default } from './Button.tsx';

// SomePage1.tsx
import OldButton from './component/Button';

// SomePage2.tsx
import TestButton from './component/Button';

我假设的目标结果如下所示：

// Button/Button.tsx
export const Button = () => {};

// Button/index.ts
export { Button } from './Button.tsx';

// SomePage1.tsx
import { Button as OldButton } from './component/Button';

// SomePage2.tsx
import { Button as TestButton } from './component/Button';

我在互联网上找到的每个解决方案都只是一个代码模块，用于独立地转换每个文件，而不知道该文件之外的任何其他内容。

我开始梦想有一个解析器能够：

1. 解析项目中的所有导入并保存文件之间的关系
2. 收集有关默认导入/导出的信息
3. 为命名导出创建新的标识符名称
4. 替换存储库中的所有条目？

因此，我接受了新的挑战，开发了一个 codemod 工具，可以自动将默认导出/导入重写为命名的导出/导入。

剧透

我已经开发出来了！ ？ ？

开发流程

第一个想法
它发生在我之前的实验可视化反应组件树之后，第一个想法是重用 babel 和 webpack 插件来迭代所有模块并解析 AST，但是为什么，如果 jscodeshift 已经有了解析器，并且如果我找到了替代品webpack 插件我将能够编写一个与捆绑器无关的工具，很棒吗？

工具
好的，我有一个 jscodeshift 作为解析器。但是为了找到从入口点开始的所有文件之间的关系，我找到了resolve包，它有助于解析像原生nodejs require.resolve这样的路径，但它更类似于解析像bundlers这样的路径，你可以更好地控制扩展，同步/异步行为等

设计两步流程
我的工具的初始版本就像一个脚本中的所有内容。然而，为了提高灵活性和性能，并通过调试简化开发过程，我将该工具重构为两个阶段：

1. 数据收集：第一阶段收集代码库中默认导入和导出的所有实例

   • 我引入了一个环境变量 IS_GATHER_INFO 来控制这个阶段。该脚本使用resolve来查找默认导出/导入的每个用法
   • 另一个环境变量 ENTRY 包含代码库入口点的相对路径，从该文件开始，所有导入都将被解析和分析

2. 转换：收集数据后，第二阶段将默认导出重写为命名导出。使用 jscodeshift，我可以轻松地并行转换源代码。

   • 我引入了一个环境变量 IS_TRANSFORM 来控制这个阶段

分为以下两个步骤：

• 我能够将数据收集与转换分离，减少开发和调试期间执行的代码量和花费的时间
  • 这是查看 GatherInfo 函数的结果、分析它、重新运行代码的非常方便的方法
  • 测试转换，无需重复运行整个管道并收集数据
• 如果您需要针对不同的入口点运行此工具但重复使用收集的数据
，收集数据转储会很有帮助

随着案例开始积累（例如动态导入、重新导出默认值、不同的导出实体：变量、函数和类以及已使用的变量问题名称），我花了更多的时间来设置测试用例。在大约 30 分钟内，我有了一个可靠的测试设置，使我能够转向测试驱动开发（TDD）

。相信我，花时间在 TDD 上这些工具是值得的，因为它们有大量的案例。您走得越远，您从测试用例中感受到的价值就越大。我想说的是，在覆盖了一半的情况后，如果你没有测试，在一个巨大的项目上运行和调试将成为一场噩梦，因为每次你需要添加一些更改，它可能会破坏很多其他情况。

AST：

我使用了以下类型的 AST 节点：

• ImportDefaultSpecifier 仅查找导入默认语句
  • 从“...”导入一些内容
• ExportDefaultDeclaration 仅查找导出默认语句
  • 导出默认的东西；
• ExportNamedDeclaration 用于查找导入默认值和导出默认值语句
  • 从 '...' 导出 { 默认值 } - 默认导出
  • 从 '...' 导出 { default as Something } - 默认导入
  • export { default } from '...' - 同时默认导入和默认导出
• ImportExpression 查找动态导入并根据需要标记该文件以保留默认导出。有些工具（例如 React.lazy）仅适用于默认导出。
  • 导入（'...'）
• 此外，我保存了有关代理文件的信息，它是导入默认内容并将该内容导出为默认内容的文件
  • 用它来查找任何文件中指定导出的新名称：file a ->文件b->文件 c

技术注意事项和已知限制
尽管该工具可以正常运行，但仍有一些边缘情况尚未处理：

命名空间.默认用法
以下代码还不会被转换：

// Button/Button.tsx
const Button = () => {};
export default Button;

// Button/index.ts
export { default } from './Button.tsx';

// SomePage1.tsx
import OldButton from './component/Button';

// SomePage2.tsx
import TestButton from './component/Button';

代理文件中的冲突
来源：

// Button/Button.tsx
export const Button = () => {};

// Button/index.ts
export { Button } from './Button.tsx';

// SomePage1.tsx
import { Button as OldButton } from './component/Button';

// SomePage2.tsx
import { Button as TestButton } from './component/Button';

结果：

import * as allConst from './const';
console.log(allConst.default);

混乱的导出，例如
来源：

export { Modals as default } from './Modals';
export { Modals } from './Modals';

将导致逻辑​​损坏，因为现在它有两个具有不同实现的相同导出：

export { Modals } from './Modals';
export { Modals } from './Modals';

前一个实体的导入也应该手动修复
来源：

export class GhostDataProvider {}
export default hoc()(GhostDataProvider);

结果：

export class GhostDataProvider {}
const GhostDataProviderAlias = hoc()(GhostDataProvider);
export { GhostDataProviderAlias as GhostDataProvider };

尽管存在这些限制，我还是在 15-20 分钟内手动修复了其余错误，并成功启动了我们的真实项目。重写默认导出。

链接

• jscodeshift
• astexplorer

就是这样，欢迎下方评论！ ？

以上是构建用于重写默认导出的 Codemod 工具的详细内容。更多信息请关注PHP中文网其他相关文章！