幹壞事是進步最大的原動力
前幾天在噗浪的偷偷說上看到有人提到 npmtrends 上的 redis (官方的) 與 ioredis：「https://www.plurk.com/p/p6wdc9」。
意外發現以下載量來看，ioredis 已經超越官方的 redis 了：
找了一下差異，看起來的確有些團隊在 loading 很高的情況下會考慮用 ioredis 取代 redis：「Migrating from Node Redis to Ioredis: a slightly bumpy but faster road」。
但沒有特別需求的話應該還是會用官方版本？
找資料的時候看到 pnpm 有在做幾個常見的 javascript package manager 的比較：「Benchmarks of JavaScript Package Managers」。
裡面測了九個項目，其中前八個剛好就是 cache 的有無、lockfile 的有無以及 node_modules 的有無，這三者的組合剛好八個，最後一個是測 update 的速度。
pnpm 因為用了 hard link，我先跳過去，只先關注 npm 與 yarn 的差異。
其中幾個比較重要的項目是 (由最重要開始列)：
在一般開發環境下，npm 比 yarn 快一些，這點讓我比較意外，我知道 npm 這幾年一直有在改善效率，但沒想到會在 benchmark 下反超，這個是以前 yarn 很大的宣傳點，現在已經不見了。
第二個是 update (upgrade) 的部份，這邊 yarn 比 npm 快一些。
第三個因為是 CI 環境，或是第一次 clone 時的環境，慢通常可以被接受，不要差太多就好，而這邊 npm 比 yarn 快一些。
但不管是哪個，差距都不像以前那麼大了，就效率上來說，官方的 npm 已經沒有太明顯的缺點，因為效率的差異而去選擇 yarn 的理由已經不存在了。
GitHub 決定擴大強制使用 2FA 的範圍：「Raising the bar for software security: next steps for GitHub.com 2FA」。
本來的 2FA policy 是在「Software security starts with the developer: Securing developer accounts with 2FA」這邊提到的，所有的使用者預定在 2023 年年底強制使用 2FA：
GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.
另外針對 npm 熱門套件的維護者，則是在三月 (top 100) 與五月 (top 500) 就強制要使用了：
In February we enrolled all maintainers of the top-100 packages on the npm registry in mandatory 2FA, and in March we enrolled all npm accounts in enhanced login verification. On May 31, we will be enrolling all maintainers of the top-500 packages in mandatory 2FA.
但到 2023 年年底才有動作會有點久，所以這次宣佈在 2023 年三月會插入一個新階段，強制這些人要有 2FA 才能進行變更類的操作：
以 developer 為主的 GitHub 大力在推 2FA，其他的服務不知道之後會不會有類似動作...
GitHub 推出了「GitHub Package Registry」，可以代管自己開發的軟體。
目前支援 npm (Node.js)、Docker、Maven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台，
隔壁 GitLab 說我們早就有了而氣噗噗中：「Packaging now standard, dependency proxy next?」。
Anyway，省下一些事情，以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用，現在看起來 GitHub 上面可以解決一些簡單的情境...
前幾天在 Twitter 上抱怨 nvm 很慢，導致 Zsh 開起來很頓 (然後也同步到 Facebook 上)：
nvm 很慢的問題還是沒解啊...
— Gea-Suan Lin (@gslin) October 14, 2017
原因在於 .bashrc 或是 .zshrc 內初始化 nvm 時會呼叫 npm config get prefix，而這個命令很慢：「`npm config get prefix` takes incredibly long (7 - 70 seconds) #14458」。
後來在 Facebook 的留言處有朋友提了幾個方案... 其中一個是 n，花了些時間看軟體架構，有夠簡單... XD 對於不是拿 Node.js 開發的人應該是夠用了 (我只拿來跑一些用 Node.js 寫的工具)。
整個軟體就一個 shell script，把他丟進 ~/bin/ 裡面 (我有把 ~/bin/ 放到 PATH 裡)，就可以用了。透過 N_PREFIX 設定他的基地 (預設是 /usr/local，我是設成 $HOME)，剩下就跑 n lts，他就把 node 與 npm 兩個檔案裝好給你用。
路徑的部份要自己設定，將 $N_PREFIX/node_modules/.bin 放進 PATH，這樣安裝起來的模組如果有可執行工具可以用才能直接跑 (像是 gulp.js 的命令)。
另外，之所以會說不適合開發者用的部份，是因為 module 是跨版本共用的 (切換 node 版本時就是用另外一個版本配上去 XD)，所以比較不適合開發者使用...
在 Python 領域裡常用 pip 安裝軟體：
$ pip install reqeusts
或是：
$ sudo pip install reqeusts
其他的平台也大致類似於這樣的動作。而在「Typosquatting programming language package managers」這篇文章裡，作者用 typo 之類的方式列出可能的名稱，像是這樣的名稱：
$ sudo pip install reqeusts
然後在這三個平台上發動攻擊，上傳了數百個套件並且觀察：
All in all, I created over 200 such packages and equipped them with a small program and uploaded them over the course of several months. The idea is to add some code to the packages that is executed whenever the package is downloaded with the installing user rights.
而這是「成果」：
在「An Analysis of the JavaScript Package Ecosystem npm」這篇看到作者把 npm 的 dependency 當作資料來源，計算出 npm 的 PageRank：
可以看到 Underscore.js 的 PageRank 一直都維持在第一位... 這個方法頗有趣的，不知道有沒有其他語言的 :o
在 Hacker News Daily 上看到可以在 command line 跟 Stack Overflow 互動的工具：「stackoverflow from the terminal」。
可以用 npm 安裝。
作者引用了 xkcd 的笑話來說明為什麼要開發這個程式：
前幾天在其他地方看到，剛剛在 Zite 上又翻到：「Use this handy command line tool to check if your code works across browsers」。
官方網站在「sgentle/caniuse-cmd」這邊，可以透過 npm install caniuse-cmd 安裝，或是加上 -g (npm install -g caniuse-cmd) 裝到系統裡。