本文将从一道小学语文题出发，由浅入深的讲述AST的设计原理以及各种衍生应用，在这过程中会手写各种好玩的插件，弄懂ESLint和代码压缩等这类基建原理，最后通过最佳实践直接助你成为基建大师。

所有人都知道 Webpack 很复杂，但 Webpack 的源码却很优雅，是一个典型的可插拔架构，不仅逻辑清晰，而且灵活好扩展。近几年出来的一些构建工具，大多也都参考了 Webpack 的这种架构方式

SSR 是 Server Side Rendering，服务端渲染，服务端返回渲染出的 html，浏览器解析 html 来构建页面。 其实这是一项很古老的技术，很早之前服务端就是通过 JSP、PHP

Babel 是一个 JavaScript 编译器，主要用于将 ECMAScript 2015+ 版本的代码转换为向后兼容的 JavaScript 语法，以便能够运行在当前和旧版本的浏览器或其他环境中。

最近在项目中使用了typescript+rollup，满心欢喜测试打包结果的时候，发现打包出来的文件竟然无法运行，具体报错如下：乍一看这个错误非常抽象，在平时的开发中也很少会遇到，定位到错误行，发现是

由于使用不当导致的内存泄漏也是一个严重的问题，作为一名合格的工程师，很有必要学习理解v8虚拟机的内存是怎么样管理的。

再初步了解了响应式的原理后，接下来我们深入响应式，解析数组响应式的原理。 对于这两种改变数据的方式，vue内部的实现并不相同。 实现原理和对象是一样的，再vm._render()时有用到list，就将依赖收集起来，重新赋值后走对象派发更新的那一套。 走对象的那一套就不行了，因为…

前几天写了一篇关于Vue 3.0 reactive API 源码实现的文章，发现大家还是蛮有兴趣对于源码这一块的。阅读的人数虽然不多，但是 200 多次阅读，还是阔以的！并且，也有同学指出了文章存在的不足，就是没有分析 Proxy 是如何配合 Effect 实现响应式的原理，即…

但是目前我们去更新数据，视图不能正常去更新，如何知道视图是否需要更新，是不是任意一组data数据修改都需要重新渲染更新视图？其实并不是，只有那些在页面被引用的数据变更后才会需要视图的更新，所以需要记录哪些数据是否被引用，被谁引用，从而决定是否更新，更新谁，这也就是依赖收集的目的…