Mako - 循环依赖检测 # 2024-09-04 by stormslowly循环依赖是代码中隐藏的风险，一些无意的改动就可能触发，并只能在运行时发现。Mako 内置循环依赖检测，让代码中的循环依赖尽快发现，排除风险。文中用到的 demo 的示例代码大家多多少少碰到过循环依赖的问题，比如变量明明导出了，但是为什么拿到的是 undefined,或者 ReferenceError: Cannot access 'foo' before initialization。最后一查，查半天，严重影响上班摸鱼时间，最后发现是循环依赖，所以对循环依赖深恶痛绝，欲除之而后快。但时候有时候发现，有些项目也有循环依赖，但是也没有任何问题，仿佛它又是人畜无害的。这些问题背后到底是为什么呢？循环依赖到底是怎么回事 # 从一个不报错的循环依赖开始 # function foo(){ bar()}function bar(){}function x(){ y()}function y(){}假设这4个函数的实现日益复杂，需要拆成两个模块，每个模块 2 个函数。那么有 3 个拆法。{foo, bar}, {x, y}{foo, x}, { bar, y }最后一种青年可能会这么拆分{ foo, y }, {bar, x}那么依赖关系就变成下图，循环依赖就形成了。但是这个循环依赖是可以正常工作的完全没有问题//index.jsimport { foo } from './m1';foo();// m1.jsimport {bar} from "./m2"export function y() { console.log("y called")}export function foo(){ bar()}// m2.jsimport {y} from "./m1"export function bar(){ console.log("bar called")}export function x(){ y()}Building with mako for development...Warning Circular Dependencies: "case1/m1.js" -> "case1/m2.js" -> "case1/m1.js"dist/index.js 9.09 kB │ map: 10.5

Mako 开源了 # 2024-06-28 by sorryccEnglish Version: Mako is Now Open Source.Hi，我是 sorrycc，Mako 的主要负责人之一，也是 Umi、Dva、Father 等库的作者。很开心，Mako 终于开源了，Github 地址是 https://github.com/umijs/mako/ ，今天和大家正式介绍下他。Mako 是什么？ # Mako 是「极快」和「生产级」的前端构建工具，基于 Rust。「极快」是我们立项做 Mako 的初衷，没有构建速度问题也就没有 Mako，参考下方的 Benchmark 区域部分数据，同时我们也一直在探索更快的构建速度方案；而「生产级」是因为 Mako 自 2023.11.24 起已在蚂蚁内部正式发布，通过工程化的方式验证了数千个项目和所有用到的 npm 包及其不同版本，已落地数百个项目，并对内服务了中后台、小程序、H5 移动端、低代码、营销、组件库、组件打包、Serverless Function 等多个不同平台和业务场景，已具备了生产级的能力。大家可以访问 https://makojs.dev/docs/features 了解 Mako 的更多特性。Mako 怎么来的？ # 去年（2023.3）我们团队立了 3 个项，Rust、SSR 和 AIGC，我们领了 Rust 方向，解构建性能的问题。我们团队一直在探索更快的构建速度方案，包括之前发布的 MFSU，都是在 Webpack 里对构建速度进行优化，这有一定的局限性。我们希望通过 Rust 来寻求这个问题的彻底解。大家可能会好奇，为啥我们不用现有 Rust 工具而是自己做一个？原因是复杂的，比如以下几点。1）当时社区库的成熟度和和蚂蚁的需求匹配度，我们在动手前调研了所有社区的 Rust 构建方案，但最终选择自研，2）主动权，业务原因，构建工具在蚂蚁会有大量定制需求，事实也是如此，我们在内部发布后，发现拿着构建这个锤子找到了很多与之匹配的钉子，3）现代的元框架是编译时框架，除了构建之外，还有大量编译需求，尤其是 SSR & RSC 的场景，比如在我们内部，RSC 场景需要 4 次构建，4）学 Rust 的需求和团队成长需求等，现代前端工具都是 Rust 编写，我们不进则退。上图是 Mako 的时间线。Ma

Mako is Now Open Source # 2024-06-28 by sorrycc中文版: 《Mako 开源了》。Hi, I am sorrycc, one of the main maintainers of Mako, and also the creator of Umi, Dva, Father, and other libraries. I am thrilled to announce that Mako is finally open source, the Github url is https://github.com/umijs/mako/ , and I’m excited to formally introduce it to you today.What is Mako? # Mako is an “extremely fast” and “production-grade” front-end build tool, based on Rust.The “extremely fast” aspect was our initial motivation for starting the Mako project. Without build speed issues, Mako would not have been necessary. Refer to the Benchmark section below for some data, and we are constantly exploring even faster build speed solutions. The “production-grade” label comes from the fact that since 2023.11.24, Mako has been officially released internally at Ant Group. It has been validated with engineering practices on thousands of projects and all used npm packages and their versions. It has been implemented in hund

Mako Tree Shaking 简介 # 2024-06-26 by stormslowly在本文开始之前需要郑重的感谢下开源前辈 Farm ，Mako 的 tree shaking 算法大量的参考(抄)了 Farm 的实现。在 Mako 实现 tree shaking 之初，我们一头雾水毫无头绪，有前辈的无私的领路才让 Mako 成为可能。感恩，感谢！什么是 tree shaking # 先看下 Wiki 上的定义。In computing, tree shaking is a dead code elimination technique that is applied when optimizing code. Often contrasted with traditional single-library dead code elimination techniques common to minifiers, tree shaking eliminates unused functions from** across** the bundle by starting at the entry point and only including functions that may be executed. It is succinctly described as “live code inclusion”.简单总结下。tree shaking 是一种死代码删除 (dead code elimination) 技术tree shaking 根据模块间（across）的信息来完成死代码的删除的Tree shaking 利用的是模块间的信息，进行的 dead code 删除。dead code 删除有很多的方式，比如代码minify 时候的 compress，但它不是 tree shaking。Tree shaking 需要利用 ESM 之间的引用信息；在某些场景下，CommonJS 之间也能分析出模块间的引用关系，也能实现 tree shaking。Bundler 的老大哥 Webpack 支持 JSON 资源的 tree shaking（你的 JSON 文件中某个字段没用到，直接帮你删了，比如 package.json 打包之后就留个 name 和 ve

Node 多线程的魔力 - Mako 中的 Less 并行编译 # 2024-06-18 by xusd320less 文件编译是每个前端通用打包工具必备的能力。在 Mako 中，对于 less 文件的编译并没有基于 rust 实现，而是通过 napi 将 less 文件交给 nodejs 的 less loader ，编译好后，再返回给 rust。Mako 的 rust 部分会根据机器配置启动线程池，将所有 cpu 都利用上，而在遇到 less 文件时，这些线程都会阻塞式等待 less loader 返回，使得在打包大量使用 less 的项目时，可能存在一定性能瓶颈。我们在使用 Mako 构建一个蚂蚁内部的大型项目时，整个构建耗时约为 21s，而 less 文件的处理约占了 5s。我们开始研究怎么给 less 编译提速。我们考虑过两种方案：用 rust 重新实现 less 编译。这就需要从 0 开始构建一个 less 编译器，成本巨大；基于 nodejs 的 worker_threads 并行编译 less。对于早期接触 nodejs 的开发者来说，可能对它的印象是：单线程，不适合做并行计算。但如今的 nodejs 已经进化了，在 10 版本就开始试验性地支持 worker 线程，12 版本提供了稳定 api。出于成本原因，我们优先尝试方案 2。在此方案下，我们需要考虑：充分利用 cpu 多核；nodejs 主线程不能阻塞住，因为 rust 通过 napi 调用 nodejs 必须经过 nodejs 主线程，如果主线程被阻塞，性能会更差;需要封装成异步 RPC 方法以保证易用性，减少对现有代码的破坏。社区对于 nodejs 线程池的封装，比较成熟的有 workerpool 、piscina 。二者的比较如下：都具备 RPC 封装，隐藏了和 worker 通信的细节（nodejs 中主线程、 worker 线程间通信是基于 MessageChannel , 和浏览器上环境中的 MessageChannel 十分接近，其底层是一个非阻塞的通信队列）；默认都实现了 FIFO 任务调度，piscina 还支持自定义调度策略;workerpool 启动时创建 worker 线程是常驻的，用完后需要手动销毁线程池，而 piscina 支持根据任务负载动态创建和销毁 worke

聊下 Mako 的 Benchmark # 2024-06-03 by sorrycc朋友们，大家好！有些同学对 Mako 的 Benchmark 感兴趣，今天就先把 Benchmark 仓库公开了。近期 Mako 正式内测，内测前我们整理了 Benchmark 仓库，基于 https://github.com/farm-fe/performance-compare 重新写了下，加了一些维度，比如 js 尺寸用于比较产物的 Tree Shaking 效果。仓库地址是 https://github.com/umijs/benchmark 。1、先看 Benchmark 结果。跑的项目是大家都在跑的 Turbopack 测试项目，跑在 M2 Pro Max 电脑上。包含维度有 dev 冷启动时间、根节点和叶子节点的 HMR 时间、生产 Build 构建时间和 JS 产物尺寸。如果大家感兴趣，可以手动 clone 仓库跑跑看。git clone [email protected]:umijs/benchmark.gitcd benchmarkpnpm ipnpm run setuppnpm benchmark注：Farm 使用 API 的方式没有尝试成功，所以没有生成 HMR 数据；RsBuild 升级 0.7 遇到点问题，所以目前还是 0.6。欢迎 PR！2、Benchmark 的实现。1）Build 速度和 JS 尺寸。没啥好说的，多跑几遍，然后算平均值就好。2）Dev 启动速度。由于 Vite 等工具按需编译功能的存在，除了要启动各个工具的 dev 命令，还需要用 puppteer 打开浏览器等 load 完成才算完，比如 Vite 这种 Bundless 的编译方式，是需要等请求过去之后才会做编译的。3）热更速度区分了 Root 和 Leaf。这应该和部分构建工具的实现有关，而在 Mako 里，Root 和 Leaf 的变更时间基本是一致的。热更的测量是往文件里 appendFileSync 一句 console.log，比如 console.log('root hmr')，然后用 page.waitForEvent 等 console 内容包含 root hmr 的事件，这样就能算出代码从改动开始到在浏览器里执行的时间差了。4）需要注意的是，有些构建工具会有缓存机制，

Mako 内测了 # 2024-05-15 by sorrycc朋友们，大家好！Mako 终于内测了。Mako 是极快和生产级的前端构建工具，基于 Rust。Mako 去年上半年立项，下半年 2023.11.24 在蚂蚁集团内部正式发布，通过工程化的方式验证了数千个项目和 npm 包，已落地数百个项目，服务了中后台、小程序、低代码、营销等多个不同平台和业务场景。经过大量项目的实践和长时间的迭代，Mako 已经成熟，在速度和产物尺寸方面都已和社区的 Rust 构建方案齐平或实现超越，现在我们决定在开源之前先做一轮内测来收集更多的反馈。Benchmark 基于 performance-compare 里的项目，相关仓库会随 Mako 一起开源。如果大家对 Mako 是如何从 0 到 1 到开源搭建出来的，我在今年 GIAC 上的分享 《Rust 构建工具在蚂蚁的研发和落地》 会详细介绍，同时会议结束后也会以文字形式分享到社区。如何参与内测 # 如果你是 Umi 用户，并且对现有项目的构建速度不满意，体验 Mako 非常简单！先确认 Umi 版本有升级到 4.2.0 或以上，然后执行 npx umi config set mako {} 命令在配置里加上 mako: {}，然后执行 umi build 或 umi dev 即可使用 Mako 进行构建。$ npx umi -v4.2.0$ npx umi config set mako {}$ npx umi build如果不是 Umi 用户，也可以一键创建 Mako + React 的项目。$ npm create mako如果你有任何问题或建议，可以在扫码加我们的微信群。或者点击以下链接加入 Telegram 群。https://t.me/+EN3fycCw3TI1NDA1同时，也欢迎大家通过 RSS 的方式订阅 Mako 的动态，我们会在这里发布 Mako 的最新消息以及和构建相关的高质量技术文章。https://makojs.dev/rss.xml致谢 # Mako 的发布离不开感谢每一位贡献者。大部分同学还是虚线业余时间参与的，感谢你们的付出！曾经给 Mako 提交过代码的同学，禾登、杰司、灏辰、伊北、棋怪、常夜、桂阳、卫初、桃树当下仍在参与 Mako 开发的同学，辟起、辟殊、无玄、油油、谦男、枭晓、云谦社区前期