likes
comments
collection
share

当你有了技术深度,很可能也同时有了技术广度

作者站长头像
站长
· 阅读数 35

很多同学不知道深入研究一些技术的意义在哪,会用不就行了?花那么大精力深入原理有什么好处呢?

这个问题就用我的两段真实学习经历来解答吧。

第一段学习经历

我刚开始写一些技术文章是研究 Babel 插件的时候,就从那里开始讲:

Babel 是一个 JS 的编译器,把高版本语法的代码,转换成低版本的代码,并且会自动引入 polyfill。

它分为三个步骤,parse、transform、generate:

当你有了技术深度,很可能也同时有了技术广度

parse 阶段把代码从字符串转换为 AST,transform 阶段对 AST 做各种增删改,generate 阶段再把转换后的 AST 打印成目标代码并生成 sourcemap。

所有的转换都是对 AST 的转换,也就是在 transform 阶段生效的。Babel 把这些 AST 转换逻辑组织成了一个个 plugin,plugin 比较多,用起来比较麻烦,所以又提供了 preset,也就是 plugin 的集合。

这样我们只需要用 preset-xx 就可以了,不用关心具体用到了啥 plugin。比如常用的 @babel/preset-env,只要指定 targets 运行环境,preset-env 内部会自动引入相应的 plugin 来做 AST 的转换。

本质上来说 babel 的核心功能就是对 AST 的各种转换,我们也可以自己写 plugin 来做这种转换。

当然,除了代码转换外,还可以静态分析,也就是通过分析 AST 来发现一些问题,在编译期间报错。

提到静态分析,自然会想到 ESLint 和 TypeScript Compiler,它俩不也是做 JS 的静态分析么?也是在编译期间发现一些代码中的问题并报错。只不过 ESLint 发现的是一些逻辑错误或者格式错误,而 TSC 发现的是类型错误。

都是基于 AST,那 Babel 能不能实现 ESLint 和 TSC 的功能呢?

于是当时我就尝试用 Babel 插件实现了下 Lint 的功能:

我发现 ESLint 里的逻辑错误的 rule 都很容易实现,因为都是对 AST 的分析。

比如 for 迭代方向的错误,就是看条件是 < 还是 >,对应的是 ++ 还是 --,基于 AST 很容易分析出来:

当你有了技术深度,很可能也同时有了技术广度

但是格式的错误就没办法了,因为 Babel 插件里拿不到这个 AST 关联的 token 信息。

我去看了下 ESLint 插件里是怎么检查出格式错误的:

发现 ESLint 提供了根据 AST 节点拿到它的 token 信息的 api,比如块语句可以拿到 { 的 token 信息,也就是所在的行列号等:

当你有了技术深度,很可能也同时有了技术广度

也可以拿到 { 的上一个 token 也就是 ) 的 token 信息,包含了行列号:

当你有了技术深度,很可能也同时有了技术广度

那这俩行列号一对比,不就知道了是不是在同一行,是不是中间有空格么?也就知道了是不是有格式问题。

ESLint 插件可以实现这种格式错误的检查,但是 Babel 插件就不可以。

是因为 AST 中不包含这部分信息么?

其实也不是,@babel/parser 也支持生成带 token 的 AST,只是没有提供对应的 api 给插件用:

当你有了技术深度,很可能也同时有了技术广度

如果 Babel 插件提供了查询 AST 节点的 token 的 api,那完全可以替代 ESLint 插件的功能。

然后我注意到 ESLint 插件提供了 fix 功能,可以自动 fix 一些错误,比较好奇它是怎么实现的,难道也是像 Babel 这样递归打印 AST 么?

研究了下发现并不是。

ESLint 插件可以在 report 错误的时候指定把某个 range 的文本替换成另一段文本:

当你有了技术深度,很可能也同时有了技术广度

原理就是字符串替换:

当你有了技术深度,很可能也同时有了技术广度

所以说,Babel 插件和 ESLint 插件至少有这两处不同:

  • ESLint 插件可以通过 api 拿到 AST 关联的 token 信息,检查出格式问题,而 Babel 插件不行
  • ESLint 的自动 fix 修改代码是通过字符串替换实现的,而 Babel 则是通过递归打印修改后的 AST 为字符串

ESLint 的静态分析搞明白了,我又在想: TSC 的类型检查不也是对 AST 做静态分析么?用 Babel 插件能实现么?

我还真实现了一个简易版的类型检查,还支持泛型和简单的类型编程:

当你有了技术深度,很可能也同时有了技术广度

但我发现有很多功能是实现不了的,比如 TypeScript 可以做跨文件的同名 namespace 合并,比如 TypeScript 可以声明跨文件的全局类型。

而 Babel 的编译是对单个文件进行的,也就是对一个文件进行 parse、transform、generate 这样的处理,下个文件再 parse、transform、generate。

TSC 会根据配置加载 lib 下的类型、加载 types 的类型,再根据 inclues、excludes、files 的配置加载项目代码里的类型,这样该放全局的放全局,该合并的合并,最后再去检查。

这种编译流程上的区别导致了 Babel 虽然可以编译 TS 代码,但并不能实现类型检查。它处理 TS 代码都是把类型语法给忽略掉的。

当然,也不只是 Babel,你用 swc、esbuild 等也是一样。

想做类型检查只能单独跑 tsc --noEmit,没有第二个选项。

搞懂了 Babel 和 ESLint、TSC 的区别,就知道为什么都是基于 AST,而 Babel 却不能取代它们两者了。

再就是代码转换,这个可是 Babel 的强项,但转换代码我们却不只用 Babel,还会用 Terser 做一次压缩(es6 之前的代码是 uglify,之后的就是 terser 了)。

为什么 Babel 明明可以在编译的过程中实现这种压缩的功能,却要用 Terser 单独来压缩呢?

其实真可以,babel 也一直在推进这事,只不过还没完成,这个 babel/minify 的项目还在 beta 阶段:

当你有了技术深度,很可能也同时有了技术广度

它的原理很容易想到,就是一系列 babel 插件来分析和转换代码:

当你有了技术深度,很可能也同时有了技术广度

前面这些编译工具都是处理 JS 的,后面我发现 postcss 就是 css 版的 babel,而且配置方式啥的都一样。

基于 postcss 同样可以实现 Lint,也就是 stylelint 工具,也同样可以实现压缩等等。

而且给 css 的 class 加 hash的 css modules 或者 scoped css 都是用它实现的。

然后我发现所有的前端编译工具都是 parse、transform、generate 这三个阶段,都是基于 AST 做分析和转换。

也很容易想明白,因为源代码和目标代码都是字符串,而中间的处理都是 AST,那自然都是这样的流程。

包括 Vue Template Compiler 也是一样,只不过它是 template 转 render function,也同样支持 transform 插件。

编译搞懂了,那自然会涉及到打包工具,因为我们一般不直接用编译工具,而是声明对什么文件用什么来编译,让打包工具去调用这些编译器,并把生成的代码打成几个 chunk。

打包工具做的事情只是根据 AST 分析出依赖图,然后对依赖图中的每个节点调用不同的编译器来编译,之后分成几个部分,包上一层 UMD 的代码生成最终的代码,当然还可以注入一些 runtime 代码。

学打包工具只需要了解 chunk 拆分、以及它的 runtime 代码做了什么事情之类的。编译和打包是两个维度的事情。

最近工具链有统一的趋势,比如 bun、rome、esbuild 等等一些工具,它们有的想把编译、Lint、压缩、打包等统一成一个工具来做,从原理上来说这是可行的,只是成本比较高,不然 babel minify 不会现在还是 beta 了。

讲了这么多,我们再回头看一下:

其实我就是研究 Babel 的时候,发现它的静态分析和 ESLint、TSC 一样都是基于 AST 做的,它的代码转换和 Terser 又有重叠部分,然后发现 postcss 也是差不多的,从而发现前端编译工具原理都类似,完全可以统一,再就是编译和打包是两个维度的事情。

我深入研究 Babel 的时候,为了搞懂它和关联的一些技术的区别,又研究了下其他技术,最终搞懂了 Babel 的同时也搞懂了很多其他工具的原理。

这就是为什么我标题说的有了技术深度的同时也会拥有技术广度。

第二段学习经历

再来举个例子,就是我最近在研究的调试:

调试我们一般用 Chrome DevTools,它可以调试网页,也可以调试 Node.js,这是为什么呢?

因为 Chrome DevTools 是基于 CDP(Chrome Devtools Protocol)和 JS 运行时通信的:

当你有了技术深度,很可能也同时有了技术广度

Node.js 之前的调试都是在命令行,没有 UI,所以对接了 CDP,这样就能直接用 Chrome DevTools 的 UI 来调试了。

当你有了技术深度,很可能也同时有了技术广度

既然只要对接 CDP 就行,那也不用非得用 Chrome DevTools 来调试,用 VSCode Debugger 也完全可以。

只不过 VSCode Debugger 多了一层适配器协议:

当你有了技术深度,很可能也同时有了技术广度

多这一层协议是 VSCode 为了让 Debugger UI 可以跨语言复用。

后来发现小程序调试工具、跨端引擎调试工具很多也都是用 Chrome DevTools 来调试,其实它们也是对接了 CDP,这样就可以用 Chrome DevTools 来调试它们的代码了。

调试工具分为 backend、frontend,UI 的部分是 frontend,代码运行时是 backend。

我试了下集成 Chrome DevTools frontend,自己实现 backend 的 CDP 服务,是可以的。这就是跨端引擎调试工具的原理。

也可以基于 JS 运行时的 backend,对接 CDP 来实现 frontend 部分。

这个过程中我了解到 Puppeteer 就是基于 CDP 实现的,它就是调试模式跑了一个 Chromium,然后连上 CDP 来做远程控制。

基于 CDP 实现这个并不难,所以我自己写了一个简易版 puppeteer。

不只是 puppeteer,lighthouse 的 cli 能拿到网页的运行数据并做一些记录和分析,也是基于 CDP 实现的。有网页分析需求的时候,也可以自己基于 CDP 这么搞。

这是我学习调试的经历:发现网页和 Node.js 的调试都可以用 Chrome DevTools 和 VSCode Debugger 调试,了解了下它们的原理都是基于 CDP,而且小程序调试工具、跨端引擎调试工具等可以用 Chrome DevTools 来调试也都是因为对接了 CDP。自己试了下实现 CDP backend 和 frontend,然后了解到 Puppeteer 和 LightHouse CLI 也都是基于 CDP 实现的,于是我实现了简易版的 Puppeteer。

我研究网页和 node 调试的过程中,顺便也搞懂了跨端引擎、小程序调试工具的原理和 Puppeteer 的原理。

这个案例也同样可以说明有了技术深度的同时也会拥有技术广度。

总结

很多技术从表面上看是毫不相关的,但再深入一点你会发现它们存在千丝万缕的关系。深入学习一门技术的同时,你也能顺蔓摸瓜掌握其他技术的原理,而且会比单独学习那门技术理解的更深。

当你有了技术深度的同时,很可能也同时有了技术广度,这俩并不冲突。

转载自:https://juejin.cn/post/7164007268952834084
评论
请登录