如何看待 Azer Ko?ulu 刪除了自己的所有 npm 庫？

12-31

// Quora 連動:https://www.quora.com/unanswered/What-conclusions-can-be-drawn-from-the-case-that-Azer-Ko%C3%A7ulu-withdrew-his-npm-libraries
// Azer 文章簡要翻譯（by justjavac）：開發者對 npm 公司不滿，unpublish 了自己的所有模塊
// Azer NPM 撤包事件全信件（中文翻譯）：【特輯】 Azer NPM 撤包事件全信件 - 【辭客堂】 - 知乎專欄
看到阮一峰老師發的Twitter：

今天凌晨，一個開發者對NPM公司不滿，unpublish了自己的所有模塊。其中包括被廣泛使用的left-pad，導致Babel、ReactNative、Ember等大量工具構建失敗。目前，Babel已經緊急發布了不包括該模塊的新版本。

I"ve Just Liberated My Modules

npmjs.org tells me that left-pad is not available (404 page) · Issue #4 · azer/left-pad · GitHub

看來npm並不認為他們有任何過錯

It was abrupt unpublishing, not our resolution policy, that led to yesterday』s disruptions.

他們認為Azer的unpublishing是魯莽和粗暴的，但Kik公司在郵件中的赤裸裸的威脅是和平友好足夠尊重的。我在推上給npm的CEO issac同志回復了一個bullshit，然後被他拉黑了，哈哈。

今後即使我仍然不得不繼續使用npm，但我絕不會向npm發布任何代碼，也一定會儘可能支持將來可能出現的npm的替代服務。當然，我說這個話是很輕鬆的，因為我並不是專業前端。如果將來我可能會專註於前端工作的話，那我一定會謀求推動一個npm的替代服務。

-----------------------------------------

這是一個令人震驚的事件，如果稍後npm公司方面不出來正式道歉的話，那麼社區一定會尋找npm的替代方案的，不會再有任何人相信npm了。

如果道歉的話，也許，只能說是也許，npm還有挽回的機會。

補充，npm恐怕已經完蛋了。。。

The fact that this is possible with NPM seems really dangerous. The author unpub...

The fact that this is possible with NPM seems really dangerous. The author unpublished (erm, "liberated") over 250 NPM modules, making those global names (e.g. "map", "alert", "iframe", "subscription", etc) available for anyone to register and replace with any code they wish.
Since these libs are now baked into various package.json configuration files (some with 10s of thousands of installs per month, "left-pad" with 2.5M/month), meaning a malicious actor could publish a new patch version bump (for every major and minor version combination) of these libs and ship whatever they want to future npm builds. Because most package.json configs use the "^1.0.1" caret convention (and npm --save defaults to this mode), the vast majority of future installs could grab the malicious version.

npm left-pad模塊刪除事件始末梳理事件起因

事件原因是在23日凌晨，一個開發者因為對NPM不滿，unpublish了自己的所有模塊。其中包括被廣泛使用的left-pad，導致Babel、ReactNative、Ember等大量工具構建失敗。

left-pad 是一個依賴度非常高的倉庫，根據 NPM 的統計顯示，left-pad 在23日時統計顯示昨日的下載量是 10 萬，上周的下載量為 57 萬，上個月下載量達到了 255 萬。

之後left-pad作者Azer在medium發布了一篇博文來闡述他刪除自己模塊的原因

I』ve Just Liberated My Modules

這裡參考justjavac提供的翻譯文章如下：

作者在《I』ve Just Liberated My Modules》文章中寫道：
幾個星期前有位專利律師給我發了一封電子郵件，要求我取消發布 NPM 上的「KIK」模塊。我的回答是「不」，於是他回復我說：「I don』t wanna be dick about it（這句就不翻譯了，你只需要知道 dick 是什麼意思就夠了），但「KIK」是我們的註冊品牌，並且我們的律師遍布世界各地。」
當我開始編寫 kik 時，並不知道有同名的公司。而我也不希望因為這個公司而被迫改變項目的名字。在遭到了我的拒絕後，他們聯繫了 NPM 的技術支持，為了強調他們的律師權力，每一個電子郵件都抄送給了我。在未經我允許的情況下，@izs 更改了此模塊的所有權。

鑒於此我才意識到，NPM 是某個人的私有地盤，他比其他人有更多的控制權，但是我是做開源的，因為權力屬於人民。（Power To The People 是約翰·列儂的同名歌曲）
概述一下就是; NPM 不再是我分享開源工作的地方，所以，我取消了曾經發布的所有模塊)。（一共取消了 273 個）
這不是一個下意識的行為。我喜歡開源，相信開源社區將最終創造一個真正自由的 NPM。
如果你的項目因此而構建失敗，我向你道歉。你可以在倉庫（azer/dependency）指出你的依賴，或者如果你自願參加我的 Github 上的任何模塊，我會高興地轉移所有權。
乾杯，再見。

npm模塊依賴的生態環境

之後有人對left-pad源碼進行查看驚訝的發現其源碼僅有11行：

module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; if (!ch ch !== 0) ch = " "; len = len - str.length; while (++i &< len) { str = ch + str; } return str; }

於是一部分的人產生了疑問：為什麼這麼短的代碼，也能成為眾多庫比如 RN 的依賴？

之後Haney的一篇博文對類似這樣的模塊進行了更多的搜索，發現了相當多類似left-pad這樣的模塊。提出了疑問：我們都忘記了怎樣去寫程序了嗎？原文在此NPM left-pad: Have We Forgotten How To Program?

這裡簡單翻譯一下他列舉的事實給大家：

好的開發者們，接下來是一個比較嚴肅的討論。正如你們可能已經知道的那樣，這一周里babel,react以及類似一大堆高依賴的模塊在npm無法被成功構建。他們宕機的原因是相當驚人的。
因為他們共同依賴了一個簡單的NPM包left-pad，它的目的是實現左填充一個字元串，他的源碼也總共只有11行。
令人擔心的是這裡有這麼多包選擇去依賴一個這樣簡單的函數，而不是採取幾分鐘去寫一個這樣的基本功能。
由於這次災難，我開始調查整個NPM的生態系統。這裡果然有一些類似的事情：

有一個叫IsArray的包，每天達到88萬的下載量，而它的源代碼僅有一行：
return toString.call(arr) == "[object Array]";

有一個判斷是否為正數的函數is-positive-integer ，源代碼只有4行，截至昨日仍然有3個項目依賴使用。後來作者重構了它依賴才變為0

一個全新安裝的babel包，包含了41000個文件

一個空白的jspm/npm-based 應用模板起始就包含了28000個文件
**這些都讓我感到相當驚訝。難道我們都忘記了怎樣編程了嗎？

看法

這次的危機算是一個潛在問題的大爆發,的確現在模塊依賴是大勢所趨，如果大量的基礎函數可以通過外部依賴解決，那麼我們自己的程序的代碼行數就可以減少很多，程序員們也可以專註於寫一些新的不同的東西。這種思想肯定是沒有問題的。

而類似Haney所列舉的這些簡單依賴包能夠產生的原因正是因為標準函數庫存在不足。讓任何人都必須寫一個左填充的字元串函數是十分荒謬的。

另外其實npm對於解決這種包名糾紛也是有很明確的規則npm-disputes。我覺得其實NPM官方的處理也不能說有太大的問題。

類似這樣的事件我認為最需要解決的兩件事是

- 語言能夠提供一個足夠健壯和充分的標準庫函數，這是解決這樣的問題的一個重要關鍵。
- NPM應該儘快解決類似這種危機的處理，出現這種問題的原因也一部分在於NPM目前沒有應對這種問題的機制，應當嘗試修改unpublish包的規則、依賴項目如果缺失嘗試尋找更多的替代品，防範其他人偽造同名庫等。

後續

npm今日在官方宣布，由於昨天的事件，今後將嚴格限制 unpublish 命令。並且，不再允許自由認領已經廢棄的模塊，必須向 npm 官方提出申請。

拋開商標權等軟體自由方面的爭論不談，這次事件也絕對是一個好事。

至少促使了部分 Node 社區甚至其他一些社區的成員開始反思生態環境的根本問題—— crowd-source 式的包平台的安全性（依賴的版本號或GUID、包的immutability），以及 micropackage 的 over-engineering 問題。像是這個 HackerNews 討論串（https://news.ycombinator.com/item?id=11348798）真的是很長一段時間來最精彩的之一。還有像是 CERT 最新發的一個 Vulnerability Note VU#319816 也有一些值得深思的觀點。

最後，不單單只是 NPM ，其他像是 PyPi 、 Gem 在內的平台都要看看能從中吸取什麼經驗教訓。

Even though you just broke my build, I applaud you for sticking to your values.

------Vinay

「軟體的自由關係到人類的自由」

是時候祭出我這篇才寫不久的科普文了：

http://mp.weixin.qq.com/s?__biz=MzA5Nzk5MzE3Ng==mid=401510950idx=1sn=f775d53fa36e2a7284eb6399e0a0f6c1scene=4#wechat_redirect

用完sinopia之後，給我團隊帶來的好處：

1、再也不需要擔心下載速度的問題了

2、解決了私有包管理的問題，可以直接向自己的伺服器內執行 npm publish

另外，這裡對於懶得自己搭建的童鞋分享兩個repo：

1、https://github.com/weflex/wpm 是我們團隊自己搭建的npm registry，可以安裝所有在npm託管的包，並且不會有任何緩存問題。

2、https://github.com/weflex/r9 是我們團隊基於nrm拓展的registry切換工具，不過如果你熟悉npmrc的用法，那就不需要這個了

只有我注意到了好幾個回答都把nodejs當做前端技術了？

說下我對這個事情技術上的看法，npm其本身設計不合理，依賴項的定位僅僅靠名稱，不像成熟的Java系列的maven那樣，有group和artifact雙重命名，構成一個依賴「坐標」，即使依賴同名也沒關係。

一個簡單的函數也定義一個模塊，不如把一系列常用，簡單的工具函數定義為一個commons模塊。僅僅提供一個簡單函數的模塊能被引用如此之多更讓我驚訝，包括一些node技術棧系列的著名工具。

回想到之前經常見到有人鼓吹的npm的模塊如此之多，可見node發展得如此之快帶來的不成熟性。

我覺得作者的做法有待商榷，不過我支持他。

雖然拜他所賜，我這兩天恐怕有得忙了……

讓一個公司或者個人獨佔某個詞語，特別是英文縮寫的使用權這種事情太瘋狂了。

畢竟英文字母就那麼幾個，你這麼玩，以後大家都用unicode來命名包吧。

還好當年微軟財大氣粗，和蘋果打了App的官司。

他們明明可以要求作者註明這個庫和他們的產品沒有關係，但是他們怎麼做的？

首先，發了個律師函給Kik的作者，要他Unpublish這個庫。

作者拒絕之後，他們找到NPM公司，通過威逼利誘的方式，讓NPM轉移了庫的所有權。

真他媽噁心！

不知道是不是下面這個玩意：

Home ? kik

--------------------------------

另外：

NPM 祝好~ 坐等這些公司一個個來折騰。

-------------------------

補充下，KIK回應了，然後公布了郵件內容

We don』t mean to be a dick about it, but it』s a registered Trademark in most countries around the world and if you actually release an open source project called kik, our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that?—?and we』d have no choice but to do all that because you have to enforce trademarks or you lose them.
Can we not come to some sort of a compromise to get you to change the name without involving lawyers? Is there something we could do for you in compensation to get you to change the name?

這是作者拒絕後KIK給作者的那封郵件，加黑是我加的。

原文：A discussion about the breaking of the Internet

我給你們講個笑話：友好的律師函。

這個故事告訴我們，node_modules打包上傳到代碼管理器並不都是愚蠢的行為。

顯示了named scope的重要性

另外大公司這樣很煩雖然可能讓自己忙活一陣但是我想說刪得好

就在我知道這件事之前幾個小時。。

我剛剛往npm上傳了一個包。。。。

眾所周知，npm搶包名已經成為了特色，並且「吃棗藥丸」。

這事情也是讓大家再一次認識到了npm的混亂。

npm確實有很多項目都是為搶包名而生，比如

npm install lovelive

這種。

這件事情影響最大的我覺得不是kik這個公司，也不是這個一氣之下下掉一堆包的開發者，應該是npm。

這件事情也算是暴露出了npm中存在的一些問題的。npm現在已經是世界第一的包管理器。就看npm如何應對和預防這類事件了。

最後，我雖然沒有把node_modules傳到github里去，但是本地代碼庫我專門開了個node_modules庫。。。。

哈哈，逃過一劫，甚至不是別人告訴我，我根本就不知道這件事情。。。

目前在做react-native，這下有得忙了

azer做法欠妥，但如果我是azer，可能也會這樣做，自己編寫的，完全有權利刪除自己寫的代碼，並不是任性，我認為azer是想喚醒大家對阻礙開源精神利益者的重視，絕不低頭，絕不妥協

另外軟體品牌Kik Messenger和KIK module完全是兩碼事，並且沒獲利也不影響Kik品牌

早上起床看新聞，發現 HN 頭條就是這個（NPM and Left-Pad: Have We Forgotten How to Program?）。跟著鏈接走了一圈，大致把事件理清了。下面說說我個人的看法吧。

首先我是支持 Azer 的做法的，刪除自己擁有的庫這是他有的權力，另外作為開源的庫，他並不需要對誰負責。最重要的是，恰巧他的庫被非常多影響力很大的庫給引用了，這才製造了這麼一個大新聞。我說這是好事，這能讓我們停下來反思（web前端發展真的是太快了）。

前面回答中很多在譴責 Azer 的，我覺得這是不對的。開源軟體在提供免費、社區維護這兩個特性的同時，也包含了更多的風險，這就是為什麼許多企業寧願從 Microsoft / Oracle 等購買服務而不自己使用和管理開源項目的原因。Windows XP 微軟從 2001 一直維護到了 2014，大家都知道去補舊版本的bug和安全漏洞是多麼痛苦的事情，但是微軟人家收了你的錢給了你承諾，他不做維護你就可以罵他，甚至還可以告他。但是 Azer 呢，人家收你錢了？還是在哪裡貼了告示說我要保證這個庫一直能用？

確實，引進包依賴會影響自身的可靠性，但我們單從代碼質量來看，引進包依賴還是不劣於自己寫的代碼的。在好的情況下，依賴的包能幫你解決各式各樣的問題，特別是涉及到兼容性、數值精度等棘手的問題時，哪怕這個包的功能非常簡單，簡單如 left-pad ，這難道不省心嗎？在不好的情況下，你發現現有包做的不好，那你完全可以不採用啊，或者心情好發個 pull request，這樣回饋社區的行為無形中又幫助到了很多依賴這個包的用戶。

而且這樣功能簡單的包的測試比較好寫。對包用戶來說，有了正確性的保證又是很省心的。很多時候我們需要一些簡單但是又懶得自己寫的代碼的時候，我們就在搜索引擎上找一下，運氣好找到 StackOverflow 上面的高票回答，就放心地 copy-and-paste。運氣不好的時候只能找到一些四周飄滿廣告的頁面，裡面用非等寬字體還沒有縮進地寫著些類似代碼的東西，思索再三要確認這段代碼能不能正常運行還不如自己寫呢。這種時候，社區維護的功能簡單的小包的好處就體現出來了。

大家都能湊合著用，大家都能回饋，我覺得這才是開源的精髓。

另外，我覺得此次事件跟 npm 是中心化的並沒有很大的關係。只要作者對自己的包有所有權，無論是不是中心化的，最終所有者都是可以決定撤下的，最多只是一個時間問題。就像 PGP Keys，儘管是分散式的存儲，但是你只要在任意一個伺服器上 revoke 了自己的 key ，一段時間內所有的伺服器就把這個消息同步好了。

這個事情倒是和 npm 的性質以及包的獲取方式有關係。 npm 是個商業公司，商業公司畢竟有自己的利益考慮（不像 Azer 那樣可以揮一揮衣袖順手帶走屬於自己的雲彩）。此次事件的導火索是 Azer 的 kik 包和 kik 公司重名了，之後被 npm 強行更換所有權。如果每個包除了自己的名字還有作者名字的話，這樣的事情也就不會發生了。另外這樣也可以防止舊的包撤下以後，惡意包冒名頂替的潛在危害。

附事件相關鏈接：

Azer Medium: Ia€?ve Just Liberated My Modules
Kik Medium: A discussion about the breaking of the Internet
Hacker News: NPM and Left-Pad: Have We Forgotten How to Program?

這個事情我覺得有兩個點需要思考的：

庫應該細到什麼粒度？
javascript社區比較極端，一個方法也要搞成個庫。java和go相對保守，代碼規模太小的與其增加依賴還不如copy。這個也和javascript增加依賴的成本較低有關係。
依賴倉庫是否應該是中心化的？庫的命名空間如何管理？
中心化的倉庫由倉庫來分配命名空間就會出現npm這種問題。如果npm在庫的命名空間前面默認增加用戶名，也不會有這個事情。但這種方式還是依賴中心倉庫來分配命名空間，如果支持搭建私服，私服的命名空間可能和中心倉庫衝突。個人認為倉庫應該是個規範，命名空間用域名的方式來約定。比如java的maven倉庫是沿用package的命名規範，也就是域名倒寫的方式，這樣就很大程度避免了命名衝突的問題，也不會有商業上的法律問題，比如我的庫如果叫做 com.jolestar.kik ，kik公司也沒有權利要求我改名吧。

最大的安全隱患就是別人搶注了包名，寫惡意腳本，你能npm install 的時候能以當前用戶許可權執行任何腳本！如果用sudo 安裝的話更是能為所欲為！

npm 的安全隱患這麼大，居然一直沒引起廣泛關注。

這就是為什麼很多大公司，都不喜歡使用所有權有隱患的項目。小弟弟捏在對方手裡，隨時隨地會爆。當年KDE所用的QT，license有問題，結果幾個巨頭就全力支持GNOME。

這件事情最大的受害者恐怕是NPM公司。後面只要Google、Facebook、Microsoft之類的大公司發起一個類似Eclipse基金會一樣的項目試圖取而代之，它就完蛋了。

從前我不知道這個人，今天我知道了，而且我在他的 left-pad 項目加了個星，因為我覺得他只做了一件事，而且把他做好了 GitHub - azer/left-pad: String left pad

我只想說，勇士，請受我一拜 _(:3」∠)__

當年Linus不開心，git就誕生了。npm小心啊

是時候考慮去中心化的依賴構建了，趁現在還不晚。