想想项目创建之后，多久没给 npm 依赖升级了？

如何得知当前项目 npm 依赖的“健康度”？

给老项目升级 npm 依赖，有哪些注意事项？

在过去，request 模块几乎是 Node.js 端的不二选择，可惜已被放弃维护。如今流行的模块虽然变多，但不意味着它们足够成熟，我还是倾向于专注 Node.js 端的那几个。

需求越简单，选择越不重要。不过相较而言，Got 的接口设计看起来更友好，并且它是做到支持 Connection Timeout 和 Read Timeout 的少数。

见 https://github.com/sindresorhus/got/#comparison 的 Advanced timeouts

实际用下来，还是遇到了坑，顺便扒了一眼 Got 的代码。

想向同事分享窗口切换的一点心得，不小心写成一篇没什么营养的方法论。虽然主要还是讲窗口切换。

SSR 是一项资源密集型任务，要抵抗更大流量、提供更快的服务，缓存是其中的必修课。

而 CDN 缓存——作为静态资源的首要支撑，适合武装到 SSR 页面吗？

前言

4 月 25 日，NPM 社区又一次因更新事故引燃技术圈的讨论，导火索便来自名为 is-promise 的包。

网上盛传一个单行代码的包影响到了谷歌、FaceBook、亚马逊等众多大咖的知名项目，也有人扬言它使几乎整个 JavaScript 生态陷入了混乱。

不过“雪崩”之时，我和身边人都没有体会到震感，不禁疑惑，平时很少有场景需要判断某个值是否为 Promise，如此名声不显、功能又不重要的 NPM 包，真的有这么大的影响和破坏力吗？

既是好奇心的驱使，也是不认同部分夸张的言辞，我决定向前一探究竟。

dist-tag 是广为 npm 包开发者所熟知的属性，如果不是今天碰到一个有趣的问题，我根本没想过拉它出来玩。

为了照顾不曾了解 dist-tag 的用户，我先用一句话介绍 —— dist-tag 是 npm 版本号的命名空间，而 latest 则是默认的命名空间。想必大家不会陌生 npm install <name>@latest 这样的用法吧。

更重要的是，除非 package.json 中有所指定，所有安装默认在 latest 空间下匹配版本号。而处在 latest 空间时，也不会去名为 beta 的 dist-tag 下查找版本号。

那么问题来了！设想一个 npm 包首次发布就使用 beta 作为 dist-tag，它可以被 npm install <name> 安装吗？

过去两年，不论我安装、切换到哪家浏览器，除了已逝的 Vimperator，Vimium 都是第一个安装的插件。

曾经偶然听闻 qutebrowser 大名，但得知它没有让我难以割舍的 Dark Reader 插件，因此擦肩而过。

然而 Vimium 的小缺陷屡屡挑衅我的耐心，直到真正开始使用 qutebrowser，终于让我下定了迁移的决心。

本篇将讨论如何解决 Verdaccio 官方本地存储方案不支持 Cluster 的问题。

Why

npm 的安装出错是屡见不鲜，往往是因为安装的环境不够 “clean”。

通常情况下，只要删除项目目录的 node_modules 和 package-lock.json，重新执行 install 就能解决。

偶尔也会出现上述操作解决不了的问题，譬如 npm 的缓存文件异常，就需要在安装前执行 npm cache clean --force 清空缓存目录。

但 npm cache clean 也存在两个未处理的缺陷，使它既不完全可靠又具备风险。

前言

这里的 Verdaccio 是指用于搭建轻量级 npm 私有仓库的开源解决方案，以下简称 npm 私服。

前段时间写了一点分流相关的优化思路，但那是以节省资源开销为主、不冲破原有结构的微调，从结果上看，甚至不是合格的优化。

随着用户（请求）数量的上升，服务响应速度和效率其实才是最要紧的问题，节省资源终究不能改善这一点。因此我决定实施上次浮现在脑中的想法，将内外网的 npm 包流量彻底分流。