npm uninstall --no-save | N/A | N/A | N/A |
|
일반적으로 사용되는 명령
이 표에는 유용한 내장 명령이 포함되어 있습니다. 공식 명령이 없는 경우 일반적으로 npm 包或 Yarn Berry 플러그인을 통해 타사 명령을 사용할 수 있습니다.
| Action |
npm |
Yarn Classic |
Yarn Berry |
pnpm |
| Publish |
npmPublish |
yarnPublish | yarn npm 게시 |
pnpm 게시 |
| 목록 설치됨 deps |
npm ls 별칭: list, la, ll |
yarn list |
|
pnpm 목록 별칭: ls |
| list old deps |
npm outdated |
yarn outdated |
yarn 업그레이드-인터랙티브 |
pnpm 오래된 |
| deps |
npm에 대한 정보 인쇄 ntl 별칭 설명: 왜 |
yarn 왜 ntl |
like Classic |
pnpm 왜 ntl |
| init 프로젝트 |
npm init -y npm init(대화형) 별칭 s : --yes |
yarn init -y Yarn init(대화형) 별칭: --yes |
yarn init |
pnpm init -y pnpm init(대화형) 별칭: --yes |
| 라이센스 인쇄 정보 |
N / A(타사 패키지를 통해) |
실 라이센스 목록 |
N/A(또는 plugin, 기타 plugin을 통해) |
N/A(타사 패키지를 통해) |
| 업데이트 패키지 관리자 버전 |
N/A(타사 도구 포함, 예: nvm) |
npm 포함: 원사 정책 세트 버전 1.13.0 |
Corepack 포함: 원사 세트 버전 3.1.1 |
N/A(npm 포함, Corepack ) |
| 보안 감사 수행 |
npm audit |
yarn audit |
yarn npm audit |
pnpm audit |
| semver 없이 package.json에 deps 추가 |
npm i -E 반응 별칭: --save - 정확한 |
yarn 추가 -E 반응 별칭: --exact |
like Classic |
pnpm 추가 -E 반응 별칭: --save-exact |
| deps를 제거하고 package.json에서 제거 |
npm 제거 반응 별칭 : 제거, rm, r, un, unlink |
yarn 제거 반응 |
like Classic |
pnpm 제거 반응 별칭: rm, un, uninstall |
| uninstall deps w/o update of package.json |
npm uninstall - - 저장 안 함 |
N/A |
N/A |
N/A |
配置文件
配置包管理器发生在您的 package.json 和专用的配置文件中。
- 定义要使用的准确版本
- 使用特定的依赖解决策略
- 配置私有注册表
- 告诉包管理器在哪里可以找到
monorepo 中的工作区
npm
大多数配置发生在专用配置文件 .npmrc 中。
如果你想使用 npm 的 workspaces 功能，你必须在 package.json 中添加workspaces 元数据字段来告诉 npm 在哪里可以找到子项目或工作空间的文件夹。
// ...
"workspaces": [
"hooks",
"utils"
]
}
로그인 후 복사
每个包管理器都可以使用公共 npm 注册表。或许你很可能希望重用它们而不将它们发布到公共注册表。您可以在 .npmrc 文件中执行此操作配置来私有注册表。( 现在基本都有私有源了)
# .npmrc
@doppelmutzi:registry=https://gitlab.doppelmutzi.com/api/v4/projects/41/packages/npm/
로그인 후 복사
npm 存在许多配置选项，最好在文档中查看它们。\
yarn
您可以在 package.json 中设置 yarn 的 workspaces（必须是私有包）。
{
// ...
"private": true,
"workspaces": ["workspace-a", "workspace-b"]
}로그인 후 복사
任何可选配置都进入一个 .yarnrc 文件。一个常见的配置选项是设置一个 yarn-path: 它强制每个团队成员使用指定的二进制版本。yarn-path 指向包含特定 Yarn 版本的文件夹（例如 .yarn/releases/）。您可以使用命令来安装统一的 Yarn Classic 版本（classic.yarnpkg.com/en/docs/cli…）。
yarn berry
在 Yarn Berry 中配置 workspaces 和在 Yarn Classic 中的配置方式类似（package.json）。 大多数 Yarn Berry 配置发生在 .yarnrc.yml 中，并且有许多可用的配置选项。
# .yarnrc.yml
yarnPath: .yarn/releases/yarn-3.1.1.cjs
로그인 후 복사
yarn berry可以用 $> yarn plugin import <name></name> 这种导入方式来扩展插件（yarnpkg.com/cli/plugin/…），这个命令也会更新 .yarnrc.yml。
# .yarnrc.yml
plugins:
- path: .yarn/plugins/@yarnpkg/plugin-semver-up.cjs
spec: "https://raw.githubusercontent.com/tophat/yarn-plugin-semver-up/master/bundles/%40yarnpkg/plugin-semver-up.js"
로그인 후 복사
如历史部分所述，因为兼容性的关系，PnP 严格模式下的依赖关系可能存在某些问题。此类 PnP 问题有一个典型的解决方案：包扩展配置策略。
# .yarnrc.yml
packageExtensions:
"styled-components@*":
dependencies:
react-is: "*"
로그인 후 복사
pnpm
pnpm 使用与 npm 相同的配置机制，因此您可以使用 .npmrc 文件。配置私有注册表的工作方式也与使用 npm 相同。借助 pnpm 的工作空间功能可以支持多包项目。要初始化 monorepo，您必须在 pnpm-workspace.yaml 文件中指定包的位置。
# pnpm-workspace.yaml
packages:
- 'packages/**'
로그인 후 복사
Monorepo
什么是Monorepo
（这里其实就是三种概念，单仓库多项目，单仓库单项目，多仓库多项目）
monorepo 是一个包含多个项目的存储库，这些项目被称为 workspace 或者包。将所有内容保存在一个地方而不是使用多个存储库是一种项目组织策略。
当然，这会带来额外的复杂性。Yarn Classic 是第一个启用此功能的，但现在每个主要的包管理器都提供了工作区功能。本节展示如何使用每个不同的包管理器配置工作区。
npm
npm 团队在 v7 中发布了期待已久的npm 工作区功能。它包含许多 CLI 命令，可帮助从根包中管理多包项目。大多数命令可以与 workspace 相关的选项一起使用以告诉 npm 它是否应该针对特定、多个或所有工作空间运行。
# Installing all dependencies for all workspaces
$ npm i --workspaces.
# run against one package
$ npm run test --workspace=hooks
# run against multiple packages
$ npm run test --workspace=hooks --workspace=utils
# run against all
$ npm run test --workspaces
# ignore all packages missing test
$ npm run test --workspaces --if-present
로그인 후 복사
tips: 与其他包管理器相比，npm v8 目前不支持高级过滤或并行执行多个与工作区相关的命令。
yarn
2017 年 8 月，Yarn 团队宣布在workspace功能方面提供 monorepo 支持。在此之前，只能在Lerna等第三方软件的多包项目中使用包管理器。Yarn 的这一新增功能也为其他包管理器实现此类功能铺平了道路。
如果你有兴趣，可以参考如何在有和没有 Lerna 的情况下使用 Yarn Classic 的工作区功能。但是这篇文章只会介绍一些必要的命令，以帮助您管理 Yarn Classic 工作区设置中的依赖关系。
# 为所有工作空间安装所有依赖项
$ yarn
# 显示依赖关系树
$ yarn workspaces info
# 再一个包运行启动
$ yarn workspace awesome - package start
# 将Webpack添加到包
$ yarn workspace awesome - package add - D webpack
# add React 对所有包
$ yarn add react -W
로그인 후 복사
yarn berry
Yarn Berry 从一开始就以工作区为特色，因为它的实现是建立在 Yarn Classic 的概念之上的。在Reddit 评论中，Yarn Berry 的主要开发人员简要概述了面向工作空间的功能，包括：
Yarn Berry 使用大量可用于 package.json 文件的 dependencies或 devDependencies 字段的协议。其中就有 workspace协议。
与 Yarn Classic 的工作区相比，Yarn Berry 明确定义依赖项必须是此 monorepo 中的包之一。否则如果版本不匹配，Yarn Berry 可能会尝试从远程注册表获取其版本。
{
// ...
"dependencies": {
"@doppelmutzi/hooks": "workspace:*",
"http-server": "14.0.0",
// ...
}
}로그인 후 복사
pnpm
通过 workspace 这种协议，pnpm 促成了类似于 Yarn Berry 的 monorepo 项目。许多 pnpm 命令接受 --recursive (-r) 或者 --filter 这种在 monorepo 上下文中特别有用的选项。它的原生过滤命令也是对 Lerna 的一个很好的补充。
# prune all workspaces
pnpm -r exec -- rm -rf node_modules && rm pnpm-lock.yaml
# run all tests for all workspaces with scope @doppelmutzi
pnpm recursive run test --filter @doppelmutzi/`
로그인 후 복사
性能 & 磁盘效率
性能是选型决策的关键部分。本节展示了基于一个小型和一个中型项目的基准测试。以下是有关示例项目的一些说明：
- 两组基准都不使用工作区功能
- 小项目指定33个依赖
- 中项目指定44个依赖
我用三个用例 (UC) 对我们的每个包管理器变体进行了一次测量。要了解详细的评估和解释，请查看项目 1 (P1)和项目 2 (P2)的结果。
- UC 1：没有缓存/存储，没有锁定文件，没有
node_modules或 .pnp.cjs
- UC 2：存在缓存/存储，没有锁定文件，没有
node_modules 或 .pnp.cjs
- UC 3：存在缓存/存储，存在锁定文件，没有
node_modules 或 .pnp.cjs
我使用工具gnomon来测量安装消耗的时间（ yarn | gnomon ）。此外我测量了生成文件的大小 $ du -sh node_modules。
| Performance results for Project 1 |
|
|
|
|
|
|
|
| Method |
npm v8.1.2 |
Yarn Classic v1.23.0 |
pnpm v6.24.4 |
Yarn Berry PnP loose v3.1.1 |
Yarn Berry PnP strict v3.1.1 |
Yarn Berry node_modules v3.1.1 |
Yarn Berry pnpm v3.1.1 |
| UC 1 |
86.63s |
108.89s |
43.58s |
31.77s |
30.13s |
56.64s |
60.91s |
| UC 2 |
41.54s |
65.49s |
26.43s |
12.46s |
12.66s |
46.36s |
40.74s |
| UC 3 |
23.59s |
40.35s |
20.32s |
1.61s |
1.36s |
28.72s |
31.89s |
| Files and size |
package-lock.json: 1.3M node_modules: 467M |
node_modules: 397M yarn.lock: 504K |
pnpm-lock.yaml: 412K node_modules: 319M |
yarn.lock: 540K cache: 68M unplugged: 29M .pnp.cjs: 1.6M |
yarn.lock: 540K cache: 68M unplugged: 29M .pnp.cjs: 1.5M |
node_modules: 395M yarn.lock: 540K cache: 68M |
node_modules: 374M yarn.lock: 540K cache: 68M |
| Performance results for Project 2 |
|
|
|
|
|
|
|
| Method |
npm v8.1.2 |
Yarn Classic v1.23.0 |
pnpm v6.24.4 |
Yarn Berry PnP loose v3.1.1 |
Yarn Berry PnP strict v3.1.1 |
Yarn Berry node_modules v3.1.1 |
Yarn Berry pnpm v3.1.1 |
| UC 1 |
34.91s |
43.26s |
15.6s |
13.92s |
6.44s |
23.62s |
20.09s |
| UC 2 |
7.92s |
33.65s |
8.86s |
7.09s |
5.63s |
15.12s |
14.93s |
| UC 3 |
5.09s |
15.64s |
4.73s |
0.93s |
0.79s |
8.18s |
6.02s |
| Files and size |
package-lock.json: 684K node_modules: 151M |
yarn.lock: 268K node_modules: 159M |
pnpm-lock.yaml: 212K node_modules: 141M |
.pnp.cjs: 1.1M .pnp.loader.mjs: 8.0K yarn.lock: 292K .yarn: 38M |
.pnp.cjs: 1.0M .pnp.loader.mjs: 8.0K yarn.lock: 292K .yarn: 38M |
yarn.lock: 292K node_modules: 164M cache: 34M |
yarn.lock: 292K node_modules: 156M cache: 34M |
Security
npm
npm은 잘못된 패키지를 처리할 때 너무 관대하며 많은 프로젝트에 직접적인 영향을 미치는 몇 가지 보안 취약점에 직면했습니다. 예를 들어 버전 5.7.0에서는 Linux 운영 체제에서 sudo npm 명령을 실행하면 시스템 파일의 소유권을 변경npm 在处理坏包时有点过于宽容并且遇到了一些直接影响许多项目的安全漏洞。例如，在 5.7.0 版本中，当您在 Linux 操作系统上执行 sudo npm 命令时，可以更改系统文件的所有权，从而导致操作系统无法使用。
另一起事件发生在 2018 年，涉及比特币被盗。 Node.js 包EventStream在其 3.3.6 版本中添加了恶意依赖项。这个恶意包包含一个加密方法试图从开发者的机器上窃取比特币。
为了帮助解决这些问题，新的 npm 版本使用密码算法来检查您安装的软件包的完整性。SHA-512。
yarn
Yarn Classic 和 Yarn Berry 从一开始就使用校验和来检验每一个包的完整性。Yarn 还试图阻止您检索在 package.json 中未声明的恶意包：如果发现不匹配，则中止安装。
PnP 模式下的 Yarn Berry 没有传统 node_modules 方式的安全问题。与 Yarn Classic 相比，Yarn Berry 提高了命令执行的安全性。您只能执行已在 package.json 声明的包。此安全功能类似于 pnpm，我将在下面进行描述。
pnpm
pnpm 还是使用校验和来验证每个已安装包的完整性，然后再执行其代码。
正如我们在上面提到的，npm 和 Yarn Classic 都存在由于提升而导致的安全问题。pnpm 避免了这种情况，因为它的管理模型不使用提升；相反，它会生成嵌套 node_modules 文件夹，从而消除非法依赖访问的风险。这意味着依赖关系都在 .package.json 中声明了。
正如我们所讨论的，这在 monorepo하여 운영 체제를 사용할 수 없게 만듭니다. 또 다른 사건 사건
은 2018년에 발생했으며 비트코인 도난과 관련이 있습니다. Node.js 패키지 EventStream🎜은 3.3.6 버전에 악성 종속성을 추가했습니다. 이 악성 패키지에는 개발자의 컴퓨터에서 비트코인을 훔치려는 암호화 방법이 포함되어 있습니다. 🎜🎜이러한 문제를 해결하기 위해 새로운 npm 버전에서는 CryptoAlgorithm 🎜을 사용하여 설치된 패키지의 무결성을 확인하세요. SHA-512🎜. 🎜
결론
패키지 관리자마다 원칙에는 실제로 큰 차이가 있습니다.
pnpm은 CLI 사용법이 비슷하기 때문에 처음에는 npm처럼 보이지만 종속성을 관리하는 방법은 더 나은 성능을 가져옵니다. 최적의 디스크 공간 효율성을 제공합니다. Yarn Classic은 여전히 인기가 있지만 레거시 소프트웨어로 간주되어 가까운 시일 내에 지원이 중단될 수 있습니다. Yarn Berry PnP는 새로운 것이지만 패키지 관리자 세계에 다시 한 번 혁명을 일으킬 수 있는 잠재력은 아직 실현되지 않았습니다. pnpm 起初看起来像 npm，因为它们的 CLI 用法相似，但管理依赖项却大不相同；pnpm的方法带来更好的性能和最佳的磁盘空间效率。Yarn Classic 仍然很受欢迎，但它被认为是遗留软件，并且在不久的将来可能会放弃支持。Yarn Berry PnP 是全新的，但人们尚未意识到其再次彻底改变包管理器领域的潜力。
多年来，许多用户询问谁使用哪些包管理器，总体而言人们似乎对 Yarn Berry PnP
수년에 걸쳐 많은 사용자가 누가 어떤 패키지 관리자를 사용하는지, 그리고 전반적인 사람들은 Yarn Berry PnP의 성숙도와 채택에 특히 관심이 있는 것 같습니다.
이 기사의 목적은 어떤 패키지 관리자를 직접 사용할지 결정할 수 있는 다양한 관점을 제공하는 것입니다. 특정 패키지 관리자를 권장하지 않는다는 점을 지적하고 싶습니다. 다양한 요구 사항을 어떻게 평가하느냐에 따라 다르므로 원하는 것을 선택할 수 있습니다!
영어 원본 주소: https://blog.logrocket.com/javascript-package-managers-compared/노드 관련 지식을 더 보려면
nodejs tutorial🎜을 방문하세요! 🎜
![Node.js 전체 입문 튜토리얼 [es6+npm+express+webpack+promise]](https://img.php.cn/upload/course/000/000/068/6242b4c8f1a39624.png)
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
