Introduction

是什么

ESBoot是一个集 开发、测试、构建、静态检测、部署、文档、最佳实践 于一身的前端工程化工具集，旨在聚合工程化层，提高开发体验和效率，降低开发成本。

动机

源于Webpack升级

源于历史项目升级痛点带来的思考。在ESBoot之前，前端项目工程化层一直是一盘散沙，每个项目都有自己的工程化方案，导致代码冗余，维护成本高。

在webpack5发布之后，很多历史项目都需要从4升级到5，但是很难升级，本身webpack的配置就非常复杂，大版本升级更是难上加难。并且由于每个项目散落的工程化，每个人对webpack的理解也不同，导致在各个项目中有各种奇奇怪怪的定制，再考虑到升级后的稳定性，很多项目都放弃了升级。但无法升级就无法享受到webpack5带来的种种新特性。久而久之也成了人人敬而远之的历史包袱。

越是历史包袱重的项目，代码质量也会越来越差，因为给每个人的感觉就是这已经是一个屎山了，再怎么改也还是屎山，不如就在屎山上修修补补甚至添砖加瓦。

这对开发、效率提升、质量保证都是极大的阻碍。

一些优雅框架带来的思考

有痛点就有相应的解决方案，工程化的道路上也一直在进步，最开始的时候大家都是CRA来创建项目，CRA封装了工程化的配置，让开发者可以快速通过CV来创建项目。

但是CV就像泼出去的水，再想升级就就要靠自己了。

所以后续元框架开始流行，next、umi这种框架提供了更加抽象的配置。开发者可以不直接接触底层的工程化细节，只需要通过框架提供的配置项来完成配置。最重要的是他们解决了一个核心问题，就是项目的升级。比如next13版本升级到14版本，只需要把next的版本号升级，其他配置都不需要动。你可能就可以享受到webpack4升级到了webapck5的便利，并且可能他内部替换了babel到swc。这对上层来说几乎是无感知的。

并且他们都是非常优雅的，一个初始模版可能只有仅仅的几十行代码，就可以构建出一个非常复杂的项目。一切魔法的来源都是next dev、next build、next start这种命令，这种能力像潘多拉魔盒一样。

黑盒子魔法

上述所说的元框架，其实就是一个黑箱，开发者只需要知道有这么一个东西，然后就可以通过框架提供的配置项来完成配置。但是这就会带来一个问题，就是框架的配置项是有限的，无法满足所有开发者的需求。

对于企业来说，黑箱意味着不透明，意味着无法掌控，意味着风险。

所以很多企业都会选择创建自己的黑箱，这就是一个问题有很多种重复轮子的原因，但是这也是生态繁荣的标志。

ESBoot就是这样一个黑箱。

黑箱有什么

工程化

ESBoot的最大愿景就是统一工程化层，让前端项目可以像next build一样简单。再也不要碰到一个项目过了两年就是屎山项目的困境。

• 磨平工程化差异，无论你会不会webpack、vite、rollup，都可以轻松上手。
• 开发业务的时候就专注开发业务，不需要再考虑工程化的复杂性。
• 业界有新的bundler出现，webpack过时了，轻松升级一下就可以享受到新的特性。

静态检测

ESBoot内置了ESLint、StyleLint规则的最佳实践。都是无数个项目实践总结出来的最佳实践。

• 无需配置多而繁杂的规则，直接使用最佳实践。
• 磨平团队成员之间的风格差异，让团队协作更加愉快。
• 内置husky钩子，保证代码质量到最后一步。

更多功能

ESBoot尽力处理更多边界，提供更多最佳实践，使用更先进的业界工具，让代码更加稳定、开发更加高效。

• 通过plugin机制，可以轻松扩展更多功能，比如vitest插件，拒绝各种配置，只关注于单元测试本身。
• 通过bundler机制，可以基本无缝切换webpack、vite、rspack，让你享受webpack的生态、vite的极速、体验基于Rust的rspack带来的低级语言速度的震撼，而无需修改任何业务代码。
• 通过doc机制，可以轻松创建一个文档网站，无需关心任何技术细节，只需要关心内容本身。
• 内置了一键开启tailwindcss、svgr等等非常实用的工具。

愿景

一切的一切，就是为了让项目更加的稳定、高质量的同时让前端开发变得更加简单、高效、快乐。

不负如来不负卿，把更多的时间留给更美好的事物。