我正在参加「掘金·启航计划」

学习构建一个属于自己的组件库吧！

学习Vue3的你还没有自己的组件吗？快来一起构建一个吧。

本次介绍的是基于新构建工具 vite 的组件库学习。为什么要使用vite呢，快，作为风一样的男人启动速度怎么能落后呢。

这是学习然叔的小册一步一步解决问题完成的项目。参考代码hippo-ui 是我刚刚写的学习项目。分享给大家。目前只有一个可怜的Button。

项目的开始，需要从整体的角度来介绍我们将要使用的技术。分析一波优缺点

仓库管理 Monorepo

我们也许曾经听说过monorepo，但是现在可以动手用起来啦。平时我们接触的项目都是单仓库的项目，也就是每个项目都是一个文件，有且仅有一个package.json文件来控制，当项目多起来之后，并且各个项目之间互相有依赖的时候，项目之间的关系管理开始变得复杂：比如我们修改了项目A，而项目B中使用了A作为依赖，那么项目A被修改更新时就需要通知项目B，我更新了，你重新引入一下吧。我们知道工作中平时沟通的成本是很贵的，所以才要定义一系列的约定。而普通的项目管理恰恰需要实时的项目之间的沟通才能完成更新。

为了解决这个问题，Monorepo用起来，一般的Monorepo的目录如下所示，在packages存放多个子项目，并且每个子项目都有自己的package.json：

├── packages
|   ├── pkg1
|   |   ├── package.json
|   ├── pkg2
|   |   ├── package.json
├── package.json

这种结构有什么好处呢，首先我们可以看到的就是，一览全局-我们可以直观的了解到所有的项目，对于新加入的成员是很友好的吧，

试想一下。你加入了一个新的公司，拉下来一个项目，打开编辑器看了一半，emm这个依赖XXXX是什么鬼，拉下来看一下吧，再看了一会，这个依赖XXX又是什么，再拉下来看一下吧。一上午过去了，拉了5个项目一个都没看完。而使用了Monorepo就不存在这种问题了。

其次我们的同一个项目组中有些依赖是每个项目都会用到的，那么我们程序员的特色技能就可以展现出来了，共(tou)用(lan)，对于重复的依赖，外部库，提取到公共空间是完美的选择。避免了因为版本不一致导致的细微头痛的问题。

再说回上边提到的单仓库模式的问题，当我修改了项目A，项目B中永远都是最新的A的代码，不存在更新问题。团队合作更方便，各个项目We are family again了呢。

那既然说了这么多，它到底怎么用呢？

pnpm init 初始化，

然后在项目中禁用调npm和yarn，这样避免了一些兼容性问题。

"scripts": {
  "preinstall": "node ./scripts/preinstall.js"
}

packages.json中添加这条指令，添加 preinstall npm hook 钩子，这个钩子会在安装模块前触发，检查该代码是否是使用 pnpm 运行。如果不是的话会推出并提示错误。

preinstall.js文件是这样写的,这样判断如果指令不是pnpm就抛出错误不执行。

if (!/pnpm/.test(process.env.npm_execpath || '')) {
  console.warn(
    `\u001b[33mThis repository requires using pnpm as the package manager ` +
      ` for scripts to work properly.\u001b[39m\n`
  )
  process.exit(1)
}

然后初始化工作空间，在monorepo项目中项目包要在工作空间中声明。创建一个pnpm-workspace.yaml。编写如下代码告诉项目我的所有子项目都在packages目录下。

packages:
  # all packages in subdirs of packages/ and components/
  - 'packages/**'

至于我们平时安装包或者运行启动项目的命令也是有变化的

假设我们的几个子项目都需要同一个依赖，我们就会将它安装在公共空间中。如果只有某个子项目用到了，就将他单独安装在子项目中。或者安装另一个子项目作为依赖。

# 安装在workspace中(全局)
pnpm i xxx -w
# 子package安装
pnpm --filter <name> i xxx //注意 name 是子package中的package.json文件的name属性
# 内部依赖package安装(依赖另一个子项目) 将B安装到A中
pnpm --filter <A name> i <B name>

以上就是monorepo的基本使用了。那听起来这么赞的管理方式，就一点缺点都没有吗？本文最后提两点浅显的问题。

第一个就是随着子项目的数量及规模逐渐变大，我们的总仓库体积也会增长，最终会导致编译器打开速度会有明显的下降。
第二个权限管理的问题，都在一个文件里，我们如何去管理每个人的权限呢？在单文件项目中就可以很方便的操作项目权限，而在文件夹中。。。真是个让人头痛的问题呢~

你的组件库都有什么呀？我：。。。我没写过

学习构建一个属于自己的组件库吧！

仓库管理 Monorepo