依赖相关
pnpm-workspace.yaml
文件名别写错了
yarn install electron 失败
export ELECTRON_MIRROR="https://npmmirror.com/mirrors/electron/"
corepack enable
是否提交 lock.json 到代码仓库
前面我们提到 yarn 带来了 .lock 文件的机制，使得在任何环境下执行 install，都能得到一致的 node_modules 安装结果。但是是否需要提交 lockfiles(package-lock.json/yarn.lock) 到代码仓库呢？ npm 官方文档（package-lock.json | npm Docs）是建议把 package-lock.json 文件提交到代码仓库的。在多人协作的项目中，这样做确实没有问题。但是如果开发的是库，在 npm publish 的时候最好忽略 lockfiles。因为库一般是被其他项目依赖的，在不使用 lockfiles 的情况下，由于新版 npm 和 yarn 的 hoist 机制，可以复用住项目已经加载过的包，减少依赖重复和体积。
但是存在这样一种现象：即使在一些发布时忽略 lockfiles 的库中，在主项目顶层存在相关依赖包的前提下，最终生成的 lockfile 仍然没复用主项目的包。这是为什么呢？原因是库的依赖包版本和主项目存在的依赖包版本不一致。
那么如何减少库项目的依赖项呢。到这里，解决方案也就呼之欲出了：
- 库项目尽量使用和主项目版本一致的依赖包
- 在库项目 package.json 的 “peerDevpendencies” 字段中声明主项目已有的依赖包
合入其他分支代码后编译报错
相信很多同学都遇到过和我一样的问题：当自己的 feat 分支代码合入 master 或者业务班车分支的代码时，重新 yarn 时，有时候会编译失败，报大量 "can't resolve module xxx"的错误。这种错误有很多情况是依赖版本不一致的问题，但是又极其难以定位，令人头痛。那么此时有另外一个思路，那就是从 master 拉一个最新的分支再进行合入。 但更好的解决方式是：建议在日常开发过程中，定时合入 master 代码，一方面可以合入最新的 feat，另一方面可以避免长时间不合入，最后在上线阶段合入代码，可能出现大量冲突，解决不当或遗漏而造成的编译问题。同时也可以考虑将工具升级为 pnpm，以解决潜在的“幽灵依赖”和“依赖嵌套”问题，同时带来性能上的提升。