现代前端研发，多多少少都离不开依赖包的使用，在正常有网环境来说，这个没有什么问题，但是如果是内网环境（以下内网指局域网环境或无公网权限），采用物理机隔离等方式（意味着普通研发成员，无权限拷贝文件或使用网络功能），那么此时如何解决前端包依赖呢？
本篇文章主要讲解一些解决办法，不讲解具体代码实现，目前我们使用的是最后一种方案。
方案一
将依赖在外网安装一次，安装完成后，寻找有权限的人员将node_modules拷贝到内网交给你进行使用。此种方案属于暴力性质方案，不推荐。
- 优点
简单易操作，不需要额外的编码即可实现。 - 缺点
依赖文件过多，压缩慢；
包体积较大，拷贝时间长；
多人同时研发，操作麻烦，增加git仓库存放体积等
方案二（NAS + Verdaccio + Node）
此方案针对有自动同步虚拟磁盘所产生的方案，在内外网搭建一套类似于verdaccio离线仓库，然后将内外网verdaccio的缓存目录挂载到公共的虚拟磁盘上，使用时候，需要现在外网安装一次依赖，然后等待同步完成后，在内网就可以使用npm install的方式进行依赖的安装了。【注意：此方案我们之前在使用过程中，会发现外网设置缓存时候，verdaccio有时并不会讲所有离线文件下载，导致内网无法安装，之前解决办法是编写一套node服务，监听缓存目录的变化，主动下载对应离线文件包进行解决】。
- 优点
服务自动完成同步，无需手动拷贝；
仓库体积和外网一致；
迁移无需保存；
命令安装 - 缺点
同步时间长；
文件会存在冗余等
方案三（Node + Verdaccio + 手动拷贝）
此方案针仅有高层人员才有权限拿文件到内外网的情况，但又不想使用方案一的形式提供的一套方案，第一步：同样需要在内外网搭建一套类似于verdaccio离线仓库，并设置好离线仓库(有条件的同学可以再结合gitlab搭建一套文件自动拷贝到缓存目录的CD功能，方便大家都可以进行内网包发布)；第二步：使用node编写一个离线依赖下载器，研究verdaccio后可发现，只需要把依赖的tgz文件放到缓存目录，即可实现命令安装，针对此方案实现一套离线下载器，以下离线下载器的具体思路：。
1、UI
提供一套UI界面，方便所有用户使用，UI界面可以输入或者上传文件（包名/.json/.lock），demo图如下：
2、Koa制作接口
本文使用Koa作为后台服务，提供接口处理，模版渲染，可以点击Koa进行了解，当然也可使用其他方式。本步骤主要解析上传文件或者输入的内容。并转换格式传递给底层服务。
3、Node整理依赖
根据传递内容，解析dependencies，optionalDependencies，peerDependencies，bundledDependencies内部依赖项，如果是传递package.json文件，还需要解析devDependencies，并以key去下载package.json文件，npm地址/包名（如：registry.npmjs.org/tgz-get），根据下载后的json文件，获取内部versions列表，使用semver分析版本号，创建临时变量进行存储（避免有重复依赖，额外的下载工作），本文以包名：下载地址进行暂存，找到对应version后，内部有一个tarball属性，则是tgz地址，然后进行递归解析所有依赖，完成依赖包解析。
4、下载
根据解析完成的依赖描述文件，使用类似于axios以流的方式进行输出到文件，完成相应版本的tgz文件下载。
5、压缩【可选】
本文会在任务开始，生成一个临时存放的目录，用于本次下载的内容存放，下载完成后，会将整个目录压缩为tar或者zip文件包，供用户进行下载。压缩使用的是：compressing
- 优点
仓库体积和外网一致；
迁移无需保存；
压缩包体积小；
命令安装 - 缺点
需要手动拷贝到内网，然后进行解压使用；
package.json文件过多，速度较慢
6、线上地址
github：github.com/vlinr/tgz-g…
npm：www.npmjs.com/package/tgz…
方案四
本方案针对内网可访问某台公共有网机器，但只允许进不允许出提供的方案，如果不要太复杂，直接使用verdaccio做单项代理即可。此方案和有网环境基本无本质区别。
总结
通过以上几种方案，克服了目前内网前端研发的一个缺陷，大家可以自行根据自身的研发条件选择相应的方案，当然其他方案还有许多，本文只是分享目前我们使用的方案，如果有什么不足支持，欢迎大家指正。有更好的方式也欢迎大家交流。
