跳至主要內容

pnpm常用命令

Qxw大约 5 分钟技术技术文档

pnpm

pnpm 中文文档

pnpm 是一个速度快（pnpm 是同类工具速度的将近 2 倍）、磁盘空间大的软件包管理器。pnpm 使用内容可寻址文件系统将所有模块目录中的所有文件存储在磁盘上。pnpm 全称是 “Performant NPM”，即高性能的 npm。它结合软硬链接与新的依赖组织方式，大大提升了包管理的效率，也同时解决了 “幻影依赖” 的问题，让包管理更加规范，减少潜在风险发生的可能性。

安装

npm install -g pnpm
// 之后便可用 pnpm 代替 npm 命令了

常用命令

pnpm install -g    // 安装全局

pnpm uninstall -g  //  卸载全局

pnpm init // 初始化 package.json

pnpm init -y  // 初始化 package.json (跳过向导)

pnpm install  包名  --save （或者 -S ） // 用于生产环境的依赖包   ==> dependencies

pnpm install 包名 --save-dev（或者 -D ） //  用于开发环境    ==>  devDependencies

pnpm info 包名  //  查看包信息

pnpm config set registry= 镜像地址(https//registry.npm.taobao.org)  //  设置镜像路径

pnpm config set registry https://registry.npmmirror.com // 切换淘宝源

// 缓存(无效，不建议删除，确实需要删除可以找到存储路径，整个目录删除)
pnpm cache
pnpm cache list // 列出已缓存的每个包
pnpm cache dir // 返回全局缓存位置
pnpm cache clean // 清除缓存

pnpm update <package> // 更新指定包

pnpm uninstall --save <package> // 从 package.json 文件中删除依赖，需要在命令后添加参数 --save

pnpm add [package] // 添加单个包

pnpm add [package] [package] [package] // 一次性添加多个包

pnpm up                // 更新所有依赖项
pnpm upgrade [package] // 升级到最新版本
pnpm upgrade [package]@[version] // 升级到指定版本
pnpm upgrade [package]@[tag] // 升级到指定tag

支持 monorepo

monorepo(monolithic repository) 是一种项目架构，简单的来说：一个仓库内包含多个开发项目（模块，包） Monorepo 的意思是在版本控制系统的单个代码库里包含了许多项目的代码。这些项目虽然有可能是相关的，但通常在逻辑上是独立的，并由不同的团队维护。 Monorepos 有时被称为单体代码库（monolithic repositories），但不应该与单体架构（monolithic architecture）相混淆，单体架构是一种用于编写自包含应用程序的软件开发实践。

单一代码库（monorepos） vs 多代码库（multirepos）

与单一代码库相反的是多代码库（multirepos），每个项目都储存在一个完全独立的、版本控制的代码库中。多代码库是很自然的选择——我们大多数人在开始一个新项目时都愿意开一个新的代码库，毕竟谁都喜欢从 0 开始 从多代码库到单一代码库的变化就意味着将所有项目移到一个代码库中

单一代码库的好处

  • 可见性（Visibility）：每个人都可以看到其他人的代码，这样可以带来更好的协作和跨团队贡献——不同团队的开发人员都可以修复代码中的 bug，而你甚至都不知道这个 bug 的存在。

  • 更简单的依赖关系管理（Simpler dependency management）：共享依赖关系很简单，因为所有模块都托管在同一个存储库中，因此都不需要包管理器。

  • 唯一依赖源（Single source of truth）：每个依赖只有一个版本，意味着没有版本冲突，没有依赖地狱。

  • 一致性（Consistency）：当你把所有代码库放在一个地方时，执行代码质量标准和统一的风格会更容易。

  • 共享时间线（Shared timeline）：API 或共享库的变更会立即被暴露出来，迫使不同团队提前沟通合作，每个人都得努力跟上变化。

  • 原子提交（Atomic commits）：原子提交使大规模重构更容易，开发人员可以在一次提交中更新多个包或项目。

  • 隐式 CI（Implicit CI）：因为所有代码已经统一维护在一个地方，因此可以保证持续集成。

  • 统一的 CI/CD（Unified CI/CD）：可以为代码库中的每个项目使用相同的 CI/CD 部署流程。

  • 统一的构建流程（Unified build process）：代码库中的每个应用程序可以共享一致的构建流程。

单一代码库的缺陷

  • 性能差（Bad performance）：单一代码库难以扩大规模，像 git blame 这样的命令可能会不合理的花费很长时间执行，IDE 也开始变得缓慢，生产力受到影响，对每个提交测试整个 repo 变得不可行。

  • 破坏主线（Broken main/master）：主线损坏会影响到在单一代码库中工作的每个人，这既可以被看作是灾难，也可以看作是保证测试既可以保持简洁又可以跟上开发的好机会。

  • 学习曲线（Learning curve）：如果代码库包含了许多紧密耦合的项目，那么新成员的学习曲线会更陡峭。

  • 大量的数据（Large volumes of data）：单一代码库每天都要处理大量的数据和提交。

  • 所有权（Ownership）：维护文件的所有权更有挑战性，因为像 Git 或 Mercurial 这样的系统没有内置的目录权限。

  • Code reviews：通知可能会变得非常杂乱，例如 GitHub 有有限的通知设置，不适合大量的 pull request 和 code review

monorepo 的优缺点

优点

  • 代码复用非常简单
  • 简化依赖管理
  • 原子提交能让重构全局特性更容易
  • 跨组合作更方便
  • 大影响范围的重构
  • 并行构建，执行效率提升

缺点

  • 缺乏每个项目的权限控制
  • 版本信息杂糅不清晰
  • 大项目在 Git 上表现很差
  • 构建时间更长