rust实战——基于通义千问给js文件批量创建类型文件

我们需要有三个参数，一个要处理的目标路径input_path，一个要存放处理后文件的路径output_path，其中input_path可以是文件或者文件夹。两个路径需要兼顾相对路径和绝对路径。还需要有个deep♂的参数用来自定义是否需要递归子文件夹
将相对路径转换成绝对路径，然后根据路径收集文件名和文件内容
只处理export function和export const xx = () => {}这两种，所以我们需要对源码进行过滤，这里就需要将js解析成 AST
将源码发送给通义千问，让它返回给对应类型
根据目标路径的文件夹结构创建同名文件夹和文件名.d.ts

那么就先简单分析到这里。

代码架构

根据上面我们分析之后的几点，我们先完成代码的架构

有一个InputArgs，用来获取三个参数和转换成绝对路径
有一个read，用来获取文件的名字和内容，转换成File结构
要有compile，即将js源码转换成AST，并且从里面拿到符合要求的源码
要有一个ask，用来访问通义千问
要有一个write，将访问得到的内容转换成对应的文件

整理一下：

说一下为啥要这么拆分，因为这么做我们才好做单元测试

获取参数

我们在src下创建一个args的文件夹和一个mod.rs，我们直接把代码放在这个mod.rs（别忘了引入到main.rs中）就好，当然，如果你还想细分，也可以再搞其他的文件。

首先我们来设计下存放输入数据的结构和方法：

init作为入口
get_input作为数据获取的主要部分
absoluted_path将代码转换成绝对路径

然后我们先来实现get_input的部分：

这一部分我们需要获取三个参数input_path、output_path和deep，这里我们就需要借助stdout和stdin，来等待用户输入的内容

flush，刷新输出流，确保所有中间缓冲的内容能被我们拿到
read_line，这个不用多说，将拿到的数据写入path中
trim_end_matches，移除path末尾可能存在的\n

get_input主体没啥好说的，最后一个deep参数写起来有些怪，如果你有更好的方案，可以评论区说下~

在开始实现下一个方法之前，我们需要设计下测试用例，并做单元测试（后面我就不写那么详细的测试用例了，麻烦，而且占篇幅挺大的，其实就是懒，不想写）：

对应的输出（不要在意\r\n为啥不一起处理）：

然后是get_input的：

对应的输出：

ok，没问题，我们来实现第二个方法absouluted_path，即将内容转换成绝对路径

代码稍微长了些，因为我们需要判断这个路径是否是绝对路径，如果不是，我们需要转换成绝对路径，另外我们还需要确认路径是否存在，如果不存在，那么我们还需要帮他创建这个文件路径（当然你也可以直接报错不执行后续的）

canonicalize，这个方法可以把当前的相对路径转换成绝对路径，不过如果当前系统中不存在这个文件夹，那么会直接报错，所以我们还需要处理下错误的场景，帮忙创建文件夹，然后再重新将路径转换成绝对路径。
当然，要处理的目标路径这个就不需要我们帮忙创建了，如果没找到直接报错。

其它没啥好说的了，测试用例就不写了，前面说过原因了。

然后我们来实现InputArgs最后一个方法：这个方法简单，只需要组装前面两个方法即可

这个方法没啥好说的

那么到这，获取参数这一块的就完成了。

最后我们可以搞一个整体的测试用例：

这里使用了tempfile，可以创建临时文件夹

读取文件内容

我们在src下创建一个file_io文件夹，里面创建read、write和mod.rs（另外两个文件记得在mod.rs中导出）三个文件。

我们现在暂时不涉及write，我们先来实现read的逻辑。我们需要读取文件内容、文件的名字，另外如果输入的目标地址是一个文件夹，并且deep为true，那么这个时候我们就需要深度递归这个文件夹，并且记录这个过程中子文件夹的名字和路径。

这一点有些复杂，需要用到递归的逻辑，另外子文件夹的路径我们可以使用字符串拼接，然后传递给下次递归，这样可以保证路径是对的，相当于维护一个单调栈，不过是字符串的形式。

我们先设计下输出的数据的结构

name：文件名字
content：文件内容
relative_name：如果deep为true的话，那么我们还需要记录文件的相对路径，这样在生成文件的时候也能保证相对位置是正确的。

然后就是实现读取的部分，我直接贴代码了，递归相信大家都知道怎么写：

metadata，通过路径读取文件（夹）的系统信息

我们这里还单独记录了每个子文件夹的路径，这么做是为了保证输出文件在创建的过程中可以正常创建，因为最终都是绝对路径。

然后就没啥好说的了，接着也是简单的一个测试用例

然后我们把原本test/jump.js文件迁移到新建的test/haha/jump.js

就不写target_input了，直接肉眼看下是否正常：

肉眼peek正常

Compile

这部分稍微复杂一些，因为swc，这个包迭代非常非常频繁，半年前的代码现在已经不能用了（官方自己的example也有的没有更新），然后文档里面不介绍内容，需要一堆子包配合，所以比较复杂。

我们在src下创建一个compile文件夹，里面创建parse.rs、transform.rs、gen.rs、mod.rs四个文件。

在开始写代码之前，我们需要引入几个crate：

要注意包的版本，因为更新很频繁！

我们先处理parse：

这里swc依赖了一个包：scoped-tls，这个包提供了（旧）标准库的scoped_thread_local!（当前标准库的文档中没看到，只有一个thread_local!, 它用来声明一个拥有其内容的线程本地存储密钥。）的功能，可以让我们自己去impl它。

GLOBALS：来看下相关的源码：

也就是给GLOBALS创建一个ScopedKey，有点类似前端localStorage的用法。现在GLOBALS有一个全局的唯一本地线程秘钥和空间。

ScopedKey set：前面实现了ScopedKey之后拥有的方法，它接收一个参数和一个闭包，参数会在闭包运行的过程中存在，可以调用with拿到。我们这里用不到这个数据，我们用到只是因为swc官方要求的。。。
Lrc：//! Lrc is an alias of either Rc or Arc.
SourceMap：span（节点最小单位），作为span的中间器（interner）。这里面存储的span都只是指针([BytePos])指向数据的位置。简单地说，我们可以通过它拿到节点的信息。

Handler：这个就不多说了（相关的比如EmitterWriter也不多说了，会用即可），用来处理、收集错误的。
new_source_file：顾名思义，创建一个source_file，一个source_map可以存储多个source_file。
Lexer：官方没有给这货和Capturing任何的注释，但是看名字就知道是一个词法分析器，看它的配置项比如target支持设置不同的ES版本，比如ES5、ES6也可以推测出。我们暂时就不去深入了解了。
Parser：解析器
get_source_file：顾名思义，就是用来获取文件对象信息的，src即是源码，是一个Arc<String>。注意我们不能使用我们自己的源码，它内部应该是处理过的，我们后面根据节点的start和end是根据它这个处理过的源码进行定位的，所以如果我们用自己的源码容易出现偏移。

其实我也不太了解怎么用，官方没有文档介绍怎么用，迭代又非常频繁导致别人的demo很容易过期，跟着过期攻略 + 官方example自己组装的。。。以后有机会可以来分析下源码。

然后我们随便搞个测试用例：

输出结果：

可以看到和babel的AST类似，毕竟解析逻辑是一致的。

然后我们来到transform阶段，我们需要的是export function和export const xx = () => {}，所以我们需要写一个visitor用来visit所有的节点：

然后我们可以实现官方提供的Visit in swc_ecma_visit对象，它内部支持实现对不同类型节点的visit。这一点和babel的类似：

visit_export_decl：这个方法看名字就知道是用来访问export节点的，然后我们再根据它进行分析：

这里的逻辑就多说了，相信大家都看得懂。

visitor写完了，我们准备来实现接入visit的过程：

HELPERS：和Globals一样，我们需要这个HELPERS包裹，这样才能处理js中比如async这种语法。
resolver：看下官方的描述：

何时运行
解析器需要“干净”的 ast。您可以通过解析或通过删除 AST 节点中的所有语法上下文。
它有什么作用
首先，所有作用域（fn、block）都有自己的 SyntaxContext。 Resolver 访问模块中的所有标识符，并在作用域中查找绑定标识。这些标识符现在具有范围（fn， block）的 SyntaxContext。执行此操作时，解析程序会尝试将普通标识符（无卫生(hygiene)信息）解析为对范围标识符的引用。如果解析器找到合适的变量，则标识符引用将与变量具有相同的上下文。

简单地说我们可以通过它去修改节点，类似babel里的transform阶段。