内网研发，前端依赖该如何安装

• • 1. 内网研发，前端依赖该如何安装
  • • • 1.1. 发现问题
    • • 1.2. 解决问题
      • • 1.2.1. 使用本地或内网私有npm仓库
      • • 1.2.2. 预先下载并分发依赖包
      • • 1.2.3. 代理访问公网
      • • 1.2.4. 离线包管理工具
      • • 1.2.5. 内网环境内部署构建服务
    • • 1.3. 总结
      • • 1.3.1. 方案一手动拷贝
      • • 1.3.2. 方案二（NAS + Verdaccio + Node）
      • • 1.3.3. 方案三（Node + Verdaccio + 手动拷贝）
      • • 1.3.4. 方案四

内网研发，前端依赖该如何安装

发现问题

现代前端研发，多多少少都离不开依赖包的使用，在正常有网环境来说，这个没有什么问题，但是如果是内网环境（以下内网指局域网环境或无公网权限），采用物理机隔离等方式（意味着普通研发成员，无权限拷贝文件或使用网络功能），那么此时如何解决前端包依赖呢？

解决问题

在内网研发环境中安装前端依赖，主要面临的问题是没有直接访问公网的npm仓库。

为了解决这个问题，您可以采用以下几种策略：

1. 使用本地或内网私有npm仓库

a. 使用Verdaccio、Nexus或其他私有npm代理

如前所述，您可以搭建一个私有的npm服务器（如Verdaccio），它作为中间层代理，既可以缓存公共npm仓库中的包，又可以托管您的私有包。

开发者在内网环境中配置npm客户端指向这个私有服务器地址，即可正常安装依赖。

b. 内网已有企业级私有仓库

如果公司已经部署了企业级的私有npm仓库（如Sonatype Nexus或JFrog Artifactory），请按照公司提供的指引配置npm客户端，将其设置为默认registry。

2. 预先下载并分发依赖包

a. 整个项目压缩包

将包含完整node_modules目录的项目压缩包拷贝至内网环境，解压后直接使用。这种方法适用于一次性转移整个项目及其所有依赖，但不便于后续依赖升级或新增依赖的管理。

b. 手动或脚本化批量下载

在外网环境中，根据package.json或package-lock.json文件列出的依赖，逐个下载对应的tarball包（.tgz文件），然后通过文件共享、FTP、USB等方式将这些包传输到内网环境。

在内网机器上，使用npm的npm ci命令（如果存在package-lock.json）或npm install --offline --no-audit --no-fund --no-shrinkwrap --no-bin-links --no-package-lock --no-save --legacy-peer-deps命令（对于较早版本的npm可能需要额外参数）来从本地磁盘安装这些包。

3. 代理访问公网

a. 设置HTTP(S)代理

如果内网允许通过特定的HTTP(S)代理服务器访问公网，可以在内网机器上配置npm的代理设置：

npm config set proxy http://proxy.example.com:8080
npm config set https-proxy http://proxy.example.com:8080

b. SSH隧道或VPN

通过SSH隧道或公司提供的VPN连接，临时打通内网与公网的通道，然后直接使用npm install命令安装依赖。这种方式通常需要IT部门的支持和授权。

4. 离线包管理工具

a. Sinopia或cnpm镜像站

虽然Sinopia已不再维护，但部分企业可能仍沿用旧有部署。此外，国内的cnpm提供了离线npm包管理工具，可以通过离线同步功能预先下载依赖包，然后在内网环境中使用。

b. 使用其他离线包管理工具

市面上可能存在其他专门针对内网离线环境设计的包管理工具，它们可能提供更便捷的依赖包管理和同步功能。研究并评估这类工具是否适合您的内网环境。

5. 内网环境内部署构建服务

在内网环境中部署持续集成/持续部署(CI/CD)服务（如Jenkins、GitLab CI/CD、Azure DevOps等），这些服务可以定期或按需在外网环境中拉取最新依赖，构建前端项目，并将构建产物（如编译后的静态资源、打包后的JavaScript文件等）推送到内网服务器。这样，开发人员无需直接在内网环境中安装依赖，只需关注源代码的提交与合并。

综合考虑您的内网环境特点、公司政策、IT支持能力以及项目需求，选择最适合您的策略来安装前端依赖。通常，搭建并使用私有npm仓库（如Verdaccio）结合适当的离线同步机制，是兼顾长期维护性和便捷性的理想方案。

总结

方案一(手动拷贝)

将依赖在外网安装一次，安装完成后，寻找有权限的人员将node_modules拷贝到内网交给你进行使用。

此种方案属于暴力性质方案，不推荐。

• • 优点
  • • 简单易操作，不需要额外的编码即可实现。
• • 缺点
  • • 依赖文件过多，压缩慢；
  • • 包体积较大，拷贝时间长；
  • • 多人同时研发，操作麻烦，增加git仓库存放体积等

方案二（NAS + Verdaccio + Node）

此方案针对有自动同步虚拟磁盘所产生的方案，在内外网搭建一套类似于verdaccio离线仓库，然后将内外网verdaccio的缓存目录挂载到公共的虚拟磁盘上，使用时候，需要现在外网安装一次依赖，然后等待同步完成后，在内网就可以使用npm install的方式进行依赖的安装了。

【注意：此方案我们之前在使用过程中，会发现外网设置缓存时候，verdaccio有时并不会讲所有离线文件下载，导致内网无法安装，之前解决办法是编写一套node服务，监听缓存目录的变化，主动下载对应离线文件包进行解决】。

• • 优点
  • • 服务自动完成同步，无需手动拷贝；
  • • 仓库体积和外网一致；
  • • 迁移无需保存；
  • • 命令安装
• • 缺点
  • • 同步时间长；
  • • 文件会存在冗余等

方案三（Node + Verdaccio + 手动拷贝）

此方案针仅有高层人员才有权限拿文件到内外网的情况，但又不想使用方案一的形式提供的一套方案。

第一步：同样需要在内外网搭建一套类似于verdaccio离线仓库，并设置好离线仓库(有条件的同学可以再结合gitlab搭建一套文件自动拷贝到缓存目录的CD功能，方便大家都可以进行内网包发布)；

第二步：使用node编写一个离线依赖下载器，研究verdaccio后可发现，只需要把依赖的tgz文件放到缓存目录，即可实现命令安装。

方案四

本方案针对内网可访问某台公共有网机器，但只允许进不允许出提供的方案，如果不要太复杂，直接使用verdaccio做单项代理即可。此方案和有网环境基本无本质区别。

通过以上几种方案，克服了目前内网前端研发的一个缺陷，大家可以自行根据自身的研发条件选择相应的方案。