003-npm仓库
使用 nexus3 配置 npm（pnpm） 私有仓库 ¶
（一）创建 Repository ¶
1. 创建 Blob Store ¶
| 创建 npm-devops | 创建 npm-devops |
|---|---|
 |
 |
2. 创建 hosted 类型的 maven。 ¶
在企业开发中，会开发很多内部使用的库，比如自定义的工具类库、业务组件库等。这些内部私有依赖不会发布到公共的 npm 中央仓库。通过创建 hosted 类型的 npm 仓库，可以将这些内部私有依赖存储在内部仓库中，方便团队内的项目引用。这样，团队成员在构建项目时，npm 就能从这个内部仓库获取所需的私有依赖，而不需要通过其他复杂的方式来共享和管理这些依赖。
"点击 Repository -- Repositories -- Create repository -– npm(hosted) "
 |
 |
| 配置项 | 操作 / 说明 |
|---|---|
| Name | 填写 npm-local，用于自定义仓库标识，方便后续管理区分。 |
| Online | 勾选，控制仓库是否处于可访问状态，勾选后 npm 能正常与该仓库交互，取消则进入离线模式。 |
| Storage - Blob store | 下拉选择此前创建的专用 blob 存储 npm-devops，实现依赖文件的隔离存储，便于后续管理。 |
| Hosted - Deployment policy | 选择 Allow redeploy，因开发环境需支持重复发布相同版本依赖，满足迭代更新需求，若选默认的 Disable redeploy 会导致版本冲突。 |
3. 创建一个 proxy 类型的 maven 仓库。 ¶
Proxy 类型 Maven 仓库是企业 Maven 环境的 “基础组件”—— 它不生产依赖，而是外部依赖的 “缓存代理站”。通过它，既能解决外部仓库访问慢、不稳定的问题，又能统一依赖来源、保障构建一致性，是团队协作中 “提升效率、降低风险” 的关键配置。一次下载，全员复用
 |
 |
| 配置项 | 具体内容及说明 |
|---|---|
| Name | npm-proxy（自定义仓库名称，用于标识该代理仓库） |
| Maven 2 版本策略 | 保持默认配置（无需额外设置，默认支持对外部仓库中 Releases 和 Snapshots 版本的代理） |
| Proxy - Remote Storage | 远程仓库地址：https://registry.npmjs.org |
| Storage - Blob store | 选择 npm-devops（使用已创建的专用 Blob 存储，用于缓存从远程仓库下载的依赖） |
4. 创建一个 group 类型的 maven 仓库。 ¶
Group 类型的 npm 仓库是企业依赖管理的 “统一门户”，通过聚合多个仓库，既能简化项目配置、避免版本冲突，又能灵活扩展仓库结构。实际使用中，通常将其作为项目唯一的依赖来源地址，是 Nexus 仓库体系中 “提升协作效率” 的关键一环。
- Group（仓库组）：叫
npm-group，是项目唯一的 “对接窗口”（项目只配置这个仓库组的地址），本身不存依赖，只负责 “调度”； - Proxy（代理仓库）：叫
npm-proxy，对接远程公共仓库（比如 npm 中央仓库https://registry.npmjs.org），核心能力是 “拉取远程依赖并缓存”；
 |
 |
| 配置类别 | 配置项 | 具体内容 / 状态 | 说明与作用 |
|---|---|---|---|
| 基础信息 | Name | npm-group |
仓库组的唯一标识，用于管理识别及项目配置依赖源时使用。 |
| Online | 已勾选 | 启用后仓库组处于在线状态，可接收依赖请求；未勾选则离线，无法响应请求。 | |
| 存储配置 | Blob store | npm-devops |
指定专用 Blob 存储，用于存放仓库组相关的 npm 包缓存及聚合内容，实现存储隔离与管理。 |
| Strict Content Type Validation | 已勾选 | 验证上传内容的 MIME 类型是否符合 npm 仓库规范，确保存储内容合法，避免后续使用异常。 | |
| 组配置 | Member repositories | 已添加 npm-local、npm-proxy |
聚合内部私有仓库（npm-local）和外部代理仓库（npm-proxy），项目通过仓库组地址访问时，Nexus 按成员仓库优先级顺序查找依赖，实现私有包与公共包的统一获取。 |
（二）使用 nexus 构建 ¶
1. 配置私服地址 ¶
1. 复制 group 仓库地址 ¶
| 点击复制 npm-group 仓库地址 |
|---|
 |
2. 修改 npm 仓库配置 ¶
# 查看当前配置仓库
pnpm config get registry && npm config list
# 配置私服地址
pnpm config set registry http://10.10.0.5:8081/repository/pnpm-group/
# 查看效果
pnpm config get registry
# 清理 pnpm 全局依赖缓存（会删除所有已缓存的包，下次安装需重新下载）
pnpm store path
pnpm store prune
# 可选：查看缓存位置，确认是否清理成功（清理后目录会变小或为空）
npm store path
# 2. 清理项目本地残留（避免旧依赖和锁文件干扰）
rm -rf node_modules pnpm-lock.yaml # Linux/macOS
2. 拉取项目编译 ¶
pnpm install --verbose
| 查看构建过程确实用到了 npm-group | 项目只对接仓库组，空仓库组让 Proxy 去远程拉依赖并缓存，Proxy 把缓存的依赖通过仓库组给项目 |
|---|---|
 |
 |
3. 拉取流程 ¶
流程拆解：项目首次拉取依赖的 5 步 “链路”
假设你现在执行 pnpm install（或 npm install），项目需要下载 vue 这个依赖（本地仓库和 Nexus 都没有），整个流程就像 “项目找 npm 仓库组要东西，仓库组让 npm Proxy 去远程 npm 源买，Proxy 买回来存好再给项目”，具体步骤如下：
1. 项目发起请求：“npm 仓库组，给我 vue！” ¶
项目的 .npmrc 配置里，只写了 npm 仓库组 npm-group 的地址（比如 http://10.10.0.5:8081/repository/npm-group/）。
当项目需要依赖时，不会直接找 npm Proxy 或远程 npm 源，而是只向 npm 仓库组发起请求：“我要 vue@3.3.4，你帮我找一下”。
2. 仓库组调度：“我这里没有，让 npm Proxy 去远程拉！” ¶
npm 仓库组 npm-group 本身不存依赖，它的作用是 “管理成员仓库的优先级”（你配置时，把 npm-proxy 加进了仓库组）。
仓库组先检查自己的 “成员仓库”：
- 首先看有没有 Hosted 私有 npm 仓库（比如
npm-local），发现里面是空的； - 再看 Proxy 仓库
npm-proxy，发现里面也没有这个依赖； - 于是仓库组告诉
npm-proxy：“你去对接的远程 npm 源（如 npm 官方源https://registry.npmjs.org/）把这个依赖拉回来”。
3. npm Proxy 拉取远程依赖：“远程 npm 源，给我寄 vue！” ¶
npm-proxy 仓库收到仓库组的指令后，会根据自己配置的 “远程 npm 源地址”（如 https://registry.npmjs.org/），向远程 npm 源发起请求：
“我需要 vue@3.3.4，麻烦发给我”。
远程 npm 源收到请求后，会把这个依赖的包文件（.tgz 等）传给 npm-proxy 仓库。
4. npm Proxy 缓存依赖：“先存起来，下次不用再跑远路了！” ¶
npm-proxy 仓库拿到远程传来的 vue 依赖后，不会直接转发，而是先做一件关键的事 ——把依赖缓存到自己的 Blob 存储（比如你配置的 npm-devops）里。
这一步就是 npm Proxy 仓库的核心价值：“首次拉取，后续复用”—— 下次再有人要这个依赖，npm-proxy 直接从缓存里拿，不用再去远程 npm 源下载（省时间、省网络）。
5. 仓库组反馈给项目：“依赖来了，拿好！” ¶
npm-proxy 仓库缓存完成后，会把依赖传给 npm 仓库组 npm-group；
仓库组再把依赖转发给发起请求的项目，项目拿到依赖后，就能继续完成开发、构建等操作。
6. 第二次拉取的变化（理解 “缓存” 的意义） ¶
如果下次另一个项目（或同一个项目再次执行 pnpm install）需要同样的 vue@3.3.4 依赖，流程会简化，跳过 “远程拉取” 步骤：
- 项目找 npm 仓库组要依赖；
- 仓库组找
npm-proxy仓库； npm-proxy仓库发现自己已经缓存了这个依赖，直接传给仓库组；- 仓库组再传给项目 —— 整个过程不用访问远程 npm 源，速度快很多。