支持自定义 Registry

[DevXiaolan]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
umi	⬜️ Ignored (Inspect)			Apr 25, 2023 2:34pm

[fz6m]

registry 是很长比较难记忆的，就算记住了，每次创建项目要手动输入一长串 url 也是不友好的，没人会这么做，实用性不大。

如果你想用自己的 registry，创建完删掉 .npmrc 或者修改对应的 registry 字段即可。

这个地方如果非要做的话，应该自动识别当前用户全局的 registry 配置，同时和 npm 官方源与 npmmirror 源做对比，处理掉所有的 edge case ，包括 npmjs.org / npmjs.com / taobao.com / .com/ / .com 等，如果真正确定用户有自己的源，这个源可以作为第三个选项出现。

[DevXiaolan]

registry 是很长比较难记忆的，就算记住了，每次创建项目要手动输入一长串 url 也是不友好的，没人会这么做，实用性不大。

如果你想用自己的 registry，创建完删掉 .npmrc 或者修改对应的 registry 字段即可。

这个地方如果非要做的话，应该自动识别当前用户全局的 registry 配置，同时和 npm 官方源与 npmmirror 源做对比，处理掉所有的 edge case ，包括 npmjs.org / npmjs.com / taobao.com / .com/ / .com 等，如果真正确定用户有自己的源，这个源可以作为第三个选项出现。

道理是这个道理，不过目前创建之后就直接安装依赖了，这个过程就是纯浪费的。换一个角度初始化项目这个场景也不是经常发生，copy一个url实际上还能接受。这个功能对于使用内部源的企业，就十分的爽感。

[DevXiaolan]

是的，但是内部源有很多种情况：

1. 第一种是大公司，或者有统一网关的公司，默认将 taobao 源和官方源代理到了内部源，即使你配了其他源，照样只会连接到内部源，对这种用户来说，他选什么源都一样。
2. 第二种是不锁 lock 文件的公司，这类公司只需全局配一个源，本地无需配任何源，lock 文件对他来说没用。
3. 第三种是中型公司，往往是自建 cnpm ，但还要考虑两个因素：① 是否限制了只能发布某些 scope ，② 内部源能否支持千人研发下载成本，这种情况一般我们指定默认源是淘宝源，某个 scope 下走公司内源是最佳解，因为成本限制，内部源顶不住那么多人同时访问，代理下载所有包的话是速度比较慢的，体验不好：

     # 最佳实践
     registry=https://registry.npmmirror.com/
     @scope:registry=https://内网源

4. 最后是小公司，一般是 cnpm 或 verdaccio 、云服务商的 npm 服务，这种情况是比较适合你说的全部走代理，因为访问量比较小，但项目是 3-5+ 年的话，有十万依赖文件，就会变慢了，因为机器限制水管和并发没那么大，此时就要演变到 3 。

我认为折中，配双源是任何公司的最佳实践，无需全局代理公司源，除非是内网隔离开发。

巧了，我们就是隔离开发

[DevXiaolan]

有其他 opinions 吗？没有就close了

[fz6m]

优化了下，可以解你的问题，但这么做会让 create-umi 启动慢 1s ，还没想好收益如何 👀

[DevXiaolan]

优化了下，可以解你的问题，但这么做会让 create-umi 启动慢 1s ，还没想好收益如何 👀

感觉不错

[DevXiaolan]

你们还好吗

[DevXiaolan]

是的，但是内部源有很多种情况：

1. 第一种是大公司，或者有统一网关的公司，默认将 taobao 源和官方源代理到了内部源，即使你配了其他源，照样只会连接到内部源，对这种用户来说，他选什么源都一样。
2. 第二种是不锁 lock 文件的公司，这类公司只需全局配一个源，本地无需配任何源，lock 文件对他来说没用。
3. 第三种是中型公司，往往是自建 cnpm ，但还要考虑两个因素：① 是否限制了只能发布某些 scope ，② 内部源能否支持千人研发下载成本，这种情况一般我们指定默认源是淘宝源，某个 scope 下走公司内源是最佳解，因为成本限制，内部源顶不住那么多人同时访问，代理下载所有包的话是速度比较慢的，体验不好：

     # 最佳实践
     registry=https://registry.npmmirror.com/
     @scope:registry=https://内网源

4. 最后是小公司，一般是 cnpm 或 verdaccio 、云服务商的 npm 服务，这种情况是比较适合你说的全部走代理，因为访问量比较小，但项目是 3-5+ 年的话，有十万依赖文件，就会变慢了，因为机器限制水管和并发没那么大，此时就要演变到 3 。

我认为折中，配双源是任何公司的最佳实践，无需全局代理公司源，除非是内网隔离开发。

现在是怎样了