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 包流量彻底分流。

背景

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

近期观察发现，有些项目依赖了名为 npm 的 npm 包，每次项目部署时都会向私服 /npm 发起请求记录，并在监控曲线上呈明显的高耗时，这引起了我们的关注。

有些项目依赖了 npm 自身的包，每次项目部署时都会产生对私服 /npm 路由的请求记录，并在监控曲线上呈明显的高耗时，这引起了我们的关注。

DataLab

近来开始读 CS:APP3e 第二章，但干看书做课后题太乏味，于是提前把 DataLab 拉出来练练。不一定是优解，趁热记录一下思路吧。

这是一篇面向 Egg.js 上层框架开发者的科普文。

Egg 官网基本做到了呈现所有“必知必会”的内容，再写一份 Egg 使用教程已经毫无必要，不如聊聊 Egg 上层框架开发过程中可能有用的技巧。