分类
npm

使用 GitHub Registry 托管私有 NPM 源

我厂有不少私有仓库,都是日常开发中提炼出来的,在几个项目中共享,比如 UI、Vuex、网络请求(axios 封装)等。以前的主要形式是使用 npm 安装 GitHub 仓库,即

npm i openresty/some-repo

这样 npm 会自动去 GitHub 查找对应的仓库,然后 clone 下来完成安装。项目中的 .npmignore 文件也会正常生效,安装后的目录会忽略不需要的文件。这样做的好处就是简单,只要仓库存在,安装依赖的系统有足够的权限(比如 ssh key),就能顺利安装。在过去的三年时间里,我们一直都这样做。

但是这样会有一些问题:

  1. package-lock.json 里记录的是 commit hash,只看这个值无法判断版本,npm 也没法使用版本号解决依赖冲突的问题。换言之,比如 A 仓库需要 C 仓库的 1 版本,B 仓库需要 C 仓库的 2 版本,那么就只能同时安装两个版本,因为 npm 无法判断两个版本是否兼容。
  2. 安装的时候要走 git clone,下载量很大,速度很慢,经常被同事吐槽。也会影响 CI 的效率。
  3. git 仓库里要提交编译后的代码,一方面浪费时间和空间,另一方面大量编译后的代码也影响 code review

所以,考虑之后决定改用 GitHub Registry。GitHub Registry 是 GitHub 提供的私有源,感兴趣的同学可以访问这个页面了解详情。这个服务需要收费,不过我厂本来就是 Team 用户,额度比较富裕,所以并没有阻力。

经过一段时间的摸索,终于搞成了,下面简单说一下做法。

对依赖项目

修改 package.json,把项目名称改成 @openresty/some-repo,即“@公司名/仓库名”。然后增加 publishConfig 字段,设置源为 GitHub registry:

{
  "publishConfig": {
    "registry": "https://npm.pkg.github.com/"
  },
}

接下来,正常使用 npm publish 发布依赖即可。不过在发布之前,最好使用 .npmignore 忽略掉开发时的源文件和配置文件,一方面这些文件对于其它项目的开发没有价值,另一方面无论是存储还是下载消耗流量,都要收费,能省则省嘛。

对业务项目

因为这些依赖仓库都是私有项目,所以我们先得解决身份认证的问题。GitHub 提供了 Personal access tokens 方式,生成 token 后,添加到 ~/.npmrc 文件即可:

//npm.pkg.github.com/:_authToken=<TOKEN>

接下来,在业务项目中,添加 .npmrc 文件,指名依赖源:

registry=https://registry.npmjs.org/
@openresty:registry=https://npm.pkg.github.com

这段配置分两部分:其它域的依赖,直接从 npm 的源下载;@openresty 域下的依赖,从 GitHub Registry 下载。

最后,正常使用 npm i @openresty/some-repo 安装依赖即可。


最后的最后附上修改前后的效果对比,可以看出,改造后效果明显:

国内修改前real 0m39.543s
user 0m17.768s
sys 0m3.944s
阿里云
修改后real 0m16.450s
user 0m15.204s
sys 0m3.380s
阿里云
国外修改前real 0m49.350s
user 0m22.352s
sys 0m4.144s
阿里云
修改后real 0m30.807s
user 0m15.780s
sys 0m3.936s
阿里云
分类
npm

解决新机不能 npm install 私有仓库的问题

前些天换了电脑,从 iMac 27 Retina 2014 late 升级到 iMac 27 2019。关于前因后果,我写在张大妈,感兴趣的同学可以看下:《肉山的电子产品 篇九:机不如新,人不如故——iMac 27 换新记》

换机器要搭环境。有两个选择:

  1. 整盘复制,利用 Time Machine 之类的工具
  2. 自己慢慢搭

考虑到老电脑已经工作了 5 年,经历了小十个系统版本,各种软件删装无数,里面的垃圾很多;再加上我的环境并不复杂,所以我决定自己慢慢搭。

然后遇到一个问题:npm install 会卡住,没有明显的提示信息,只有一段比较可疑:

The authenticity of host 'GitHub.com (1.1.1.1)' can't be established.
ECDSA key fingerprint is SHA256:abcdefg.
Are you sure you want to continue connecting (yes/no)? 

因为项目中用到一些私有仓库的依赖,所以我怀疑是它们的问题。于是我把私有仓库从 package.json 里移除,再安装,成功。看来猜的没错。

然后我手动 git clone 一个项目到本地,clone 的过程中,会看到上面的提示,手动输入 yes,记录目标机器的指纹,视它安全可靠。clone 完成。再把私有仓库依赖加回 package.json,安装,成功。问题解决。

原因:使用 npm 安装 GitHub 仓库作为依赖,实际上等同于使用 git clone 将目标仓库 clone 到 node_modules 里。而 git 协议依托于 ssh 协议。在新机器上安装时,因为没有访问过目标机器,本地不信任目标机器,而 npm 又没有对这个异常做处理,所以就会卡住,不上不下。

分类
学习 技术

面试经:GitHub

GitHub 越来越有名,很多同学都把它作为一个关键字加入自己的简历当中。不过我在面试中,问到如何使用 GitHub,对方通常会答复:上去看源码呀!这个答案完全无法让我满意,具体的原因,一方面可以参考我之前的一篇文章《谈学习:读源码》,源码不是小说,直接看源码收获太小。另一方面,看源码是一个太直接的逻辑推断——上面有源码所以我去看源码——我不认为这是一个细心耕耘慢慢养成的习惯。

接下来我想简单谈一下,我认为应该如何使用 GitHub。

Issues 和 PR

一个 GitHub 仓库可不仅仅是一份源代码那么简单。GitHub 是开发者社交平台,所以每个项目在代码之外,都会有两个非常重要的模块:

  1. Issues 问题,包括 Bug,和其它使用者希望有的功能
  2. Pull Requests(PR) 其他的开发者在这个项目上做出了一些改进,或者修复了一些 Bug,希望能够合并到 master 当中,就会发起 PR

完美的代码是不存在的,越是用的人多的库,存在的问题,或者说被发现的问题可能就越多。阅读其他人提的问题,很多时候可以获得不小的收获,比如,大家开发时都遇到了什么问题?有没有与我类似的情况?他们是怎么解决的?大家最想要的新功能是什么?有哪些值得关注?我能做什么?等等。

以及,可能是更重要的,我们应该怎么样通过 Issues 与仓库的原作者进行交流。

毕竟我们每个人的时间都是有限的,对于大部分开源的类库来说,了解怎么用、有哪些问题、怎么避免踩坑,通常会比你知道它某个函数是怎么写的更有价值。

看文档

好的开源类库通常还会有一个做得非常到位的地方,便是它们的文档,做得通常详尽有价值。通过阅读文档,可以很快的了解这个仓库是干嘛用的,应该怎么用,能解决哪些问题,以及接下来,它的发展方向是怎样的。

据我观察,文档通常分布在三个地方:

  1. README.md,也就是打开仓库页面,默认渲染在文件列表下面的那块
  2. 官方网站,通常在导航下方,仓库简介那里
  3. wiki,通过导航链接可以到达

观察提交频率

并不是所有的仓库,都有开发者在进行积极地开发和维护。如果搜索到几年前的文章,被导引到一些比较古老的仓库,可能出于某种原因,已经没人对它进行维护了,这个时候,该放弃就要放弃。

人生苦短,时间有限,总会有更具价值的仓库供我们学习。

GitHub 热门趋势

GitHub 还有一个热门趋势页面,从中你可以了解到全世界的开发者都在关注哪些仓库,你可以把自己感兴趣的那些加星标记一下,将来不定时的翻一翻看一看它的 Issue、PR 和文档,通常都会有不小的收获。

GitHub Pages

GitHub 还提供给我们一个非常好的静态网站空间,完全免费,全世界都有 CDN,不用白不用。便是传说中的 GitHub Pages。

我们可以用它写博客,做笔记,重点是内容完全可以进行版本管理。

具体做法请自行 Google。

不要放弃提交自己的仓库,也应积极向别的开发者提出 Issue 和发起 PR

我觉得这件事和写博客一样,如果你只是在纸上记笔记给自己看,那多半会不求甚解;但是你想到写成博客总会有人看到,那多半还是会把要写的内容搞清楚,写全面,逻辑清晰可自洽。所以写博客是比记笔记更好的学习方法。以此类推,把自己的仓库推到 GitHub,也理应也是比在本地练习更好的学习方式。

这里绝不鼓励大家乱来,相反,我希望大家对自己的行为负责,重视 Issue 和 PR,毕竟都是提给其他开发者的,或多或少都会对别人造成影响。所以在提之前,十分有必要阅读仓库主人的提交须知,按照对方的代码规范书写代码,写好相关测试,然后再提交。做到言之有物,切不可乱来画猫。


总结

这篇文章不是传授大家应聘技巧的,而是希望分享自己的一些经验,让大家能够通过 GitHub 这个世界上最大的代码托管平台,正确的学习开发技巧。

如果您有相关的经验技巧,欢迎交流。

分类
开发工具

使用TortoiseGit+MSysGit+Github进行版本管理

以后准备都用git进行版本管理。看完 http://progit.org/book/zh/ 的1~3章, 基本就对Git有了初步的理解,接下来,就是实战了。