第五章 - 读取TypeScript AST的实用场景
探讨读取和提取AST数据最常见的应用场景
在上一章中,我们学习了如何使用Compiler API或TSQuery来读取和遍历TypeScript AST。本章我们将继续探讨读取AST能带来哪些实际好处。
开发者读取AST最主要的原因之一是创建代码检查工具,这将是我们要介绍的第一个主题。
代码检查工具(Linters)
代码检查工具用于检测代码的"正确性"。这类工具通常通过配置文件定义项目需要遵守的编码规则,然后通过高亮标记不符合规则的代码来执行这些规则。
举个例子,假设我们有一条规则:当在继承其他类的子类中创建constructor
时,必须在构造函数内调用super()
。有了这条规则后,如果我们在代码中新建一个继承类时忘记调用super()
,检查工具就会将这段代码标记为"有问题"。这样我们就能及时发现问题,避免实际错误发生。
TypeScript/JavaScript生态中有专门的代码检查工具,最流行的当属ESLint。这些工具和我们上章一样会读取代码AST,跟踪每条规则的状态,然后抛出自定义的诊断信息(警告或错误),方便用户查看和修复。
代码检查工具是AST应用的绝佳范例,为此我们专门用下一章来教你从零编写自定义检查工具!
代码格式化工具(Formatters)
代码格式化工具是另一类受益于AST分析的工具。它们与检查工具类似,也通过配置文件定义代码规范。格式化工具读取配置后分析AST,找出违反规则的代码,并能直接重写AST来自动修复问题------这是普通检查工具做不到的。
最流行的格式化工具包括:Go语言的Go fmt、JavaScript/TypeScript的Prettier、以及Rust的Rust fmt。
这些工具之所以广受欢迎,是因为它们让开发者能专注于核心逻辑,不必浪费时间手动调整代码格式以保持团队统一。
文档生成(Documentation)
通过读取AST自动生成文档是另一个超酷的应用场景。很多库和框架的文档网站都需要说明其提供的功能,而这些功能通常通过API暴露。这些API文档可以手动编写,也可以通过读取AST自动生成!
假设我们有以下带注释的导出代码:
typescript
/**
* 这个函数能完成你需要的所有功能
* 以下是它能做的事情:
* 1. 功能一
* 2. 功能二
* @param {string} input 你需要的输入参数
* @returns {Fancy} 返回你需要的Fancy类型结果
*/
export function MyToolsFeature(input: string): Fancy {
// ...
}
这段代码使用了JSDoc格式的注释。通过解析AST,我们可以提取代码和注释中的所有信息,传递给其他工具生成文档。
使用自定义脚本,我们能提取出这样的结构化数据:
json
{
"功能名称": "MyToolsFeature",
"描述": "这个函数能完成你需要的所有功能...",
"参数": [
{
"名称": "input",
"类型": "string",
"描述": "你需要的输入参数"
}
],
"返回值": {
"描述": "返回你需要的Fancy类型结果...",
"类型": "Fancy"
}
}
有成百上千的工具可以利用这类结构化数据生成完整文档网站。由于文档直接从代码生成,永远保持最新状态,完全不用担心过期问题。
功能扩展
细心的读者可能注意到,上述所有应用场景都不止于单纯读取AST。确实,它们都需要读取AST,但只有对读取的信息进行后续处理才能创造价值。
扩展代码库功能和实现自动化才是读取AST的真正威力所在。像检查工具和格式化工具,它们读取AST后可以自动修复问题或报告问题。文档生成则是将AST数据重组为其他工具(如静态站点生成器)可读的格式。
在某些情况下,我们还能利用收集的信息重写AST。后续章节将详细讨论这项技术。AST重写非常强大,像Babel这样的工具就是基于此实现的,它可以用更少的代码完成诸如将新语法转换为旧语法等强大功能,让代码能在旧版浏览器中运行。
本章小结
本章我们介绍了TypeScript AST的几个典型应用场景。接下来的章节将深入探讨读取AST后的下一步操作------通常是通过生成新AST来实现代码生成。