此篇分钟是半年前自己在组内分享的截取，关于我自己对分享主题的定义就是是主要想快速的让没接触过此类的同学有个简单的认知，有了自己的认知之后便可以自行探索了
仓库管理方式
近年来monorepo这种仓库模式非常流行，自己也是从20年便开始接触使用了，使用感受还是非常不错的。
简单介绍一下这种仓库管理模式
和普通一个包一个仓库不同，monorepo是把几个之间有所关联的包放入一个仓库中。比如vue
这种架构的经典目录结构一般都是这样的
markdown
- packages
- p1
- package.json
- p2
- package.json
- p3
- package.json
- package.json使用这种架构的一些好处
- 代码更容易管理和维护
- 提高代码重用性
- 提高开发效率
- 提高测试效率
- 提高部署效率
简单解释一下
假设一下，如果后期我们做组件库需要安装以下方式拆开分组单独发包
- 基础组件
- 高级组件
- 业务组件
- 3d组件
它们之前可能存在下面几种关系
- 高级组件、业务组件需要依赖基础组件
- 业务组件可能会依赖高级组件
- 所有组件库之间可能都会用一些相同的工具函数
- 如果升到vue3，那么所有组件库之间可能又会用到一些公用的hooks
如果现在需要开发的业务组件，真有上面1，2的这种依赖情况。我们开发时同时打开三个项目，在三个项目之间来回横跳。同时可能每个项目的基础建设都不一样，不同的lint工具、不同的格式化工具、甚至开发依赖需要不同的node版本。这显然非常影响开发心情
我们业务组件开发时，肯定需要不断的调试。普通的调试方式是将所依赖的高级组件库和基础组件库手动通过软链的方式引入过来进行测试，测试完成需要发布的时候，如果恰好三个组件库都有改动，那我们还需要分别到对应项目中执行包版本的升级和发包操作
然后使用monorepo架构之后上面这些问题都不再需要担心，架构层面的一些基础建设如：lint、构建工具、发包管理工具基本上都会复用一个。并且monorepo架构中每个关联包之间的软链也不再需要我们去手动link，统一发包时候也有相关处理工具帮我们update version逐个发布
当然这种方式也有缺点，如果设计不当
- 此仓库会变的越来越庞大，项目的下载和依赖的安装都会变得很缓慢
目前最推荐的搭建monorepo架构的方式
- pnpm workspace
我自己也有一些试例项目：
- github.com/gong-cli/te... 我自己常用的项目模版，可以使用「github.com/gong9/gong-...」进行项目的拉取
项目构建模式 bundless
这种方式也是自己今年在关注的「6月」，但是今天梳理文章的时候感觉这个东西还需要观望
因为vite的出现，现在社区中有一些库项目的构建模式方式也开始向bundless方向发展
首先做这些的前提是要基于ESM或CJS模式下的，一般组件库都会选择打出esm和umd两种模式。
- esm方便在项目里使用npm方式使用
- umd方便放到cdn以链接方式使用
但是对于传统的组件库项目来说，使用最频繁的还是直接以npm方式去引用组件，也就是esm模式的产物使用是最频繁的。具备了做bundless的前提条件
解释一下什么是bundless和bundle
我们平常未对构建产物做任何优化处理时，打出来的东西就是bundle模式。采用umi/father的解释：Bundless 即文件到文件的构建模式，它不对依赖做任何处理，只对源码做平行编译输出
它的具体优势可以看下面的测试例子的对比结果
一个例子
案例地址：github.com/gong9/bundl...
这里我写了一个对比的示例，目标是打包两个组件「button、card」
先来看一下具体产物
bundle模式 (此模式直接采用的vite进行构建)
可以看到，bundle模式下是将所有的源码打到了一个chunk下。同时做了一些转化操作
bundless模式
可以看到，bundless模式下是将所有源码基本上是按照原文件的格式进行输出(其实也会进行一些转化操作，仅是这个例子没有体现)
对比一下
bundless模式不需要手动拆包，同时因为不需要过多的代码转换操作，所以构建速度更快（本身使用者在项目进行打包时也会重新编译这些依赖部分，并不会增加多少耗时）
再来看一下构建产物的体积大小
左侧为bundless模式下的产物，右侧为bundle模式下的产物
bundless模式下的构建产物体积也是小于bundle模式的
总结：bundless模式下的包的构建速度和体积都优于普通构建