世界上還有哪些比 npm 更壞的包管理器？

01-29

當然有了，bower 就是啊

想提一個 haskell(ghc) 的 cabal 但是怕引戰……

（是的我知道 cabal 在非常努力地說自己不是包管理器，只是構建工具和框架，但是 Haskell/ghc 裡面只有 cabal 的流行程度能用來裝包啊，事實上它就是充當了包管理器的作用。）

cabal 有哪些坑呢，隨便提幾點：

1. 先後安裝和同時安裝的結果 不一樣

先後安裝就是說

cabal install A cabal install B

同時安裝就是說

cabal install A B

這裡的坑在A和B之間的依賴關係不太一致的時候，比如 A 依賴 C&>1.5 ， B 依賴 C&<1.7 ，先裝 A ，cabal 一看，C 的最新版有 1.9 了嘛，於是開心地裝了 C=1.9 和 A 。然後再裝 B ，cabal 一看，已經裝了 C=1.9 ，不能滿足 C&<1.7，於是罷工了…… 如果 A B 同時裝， cabal 就能「聰明」地發現， C=1.6 能正好滿足 A 和 B 的依賴關係，然後就開心地裝上了…裝上了…上了…了…

2. 有時要安裝某個包，必須重新安裝/編譯它依賴的包（注意不是依賴它的包）

反過來的情況容易理解，包 A 如果變化了，那麼依賴 A 的包 B 也可能要跟著變化（因爲 Haskell 還沒有穩定 ABI 的概念），於是要重新安裝/編譯 B 。

但是 cabal 這邊有的時候會遇到和別的包管理器不一樣的倒過來的情況，就是說 A 本身沒變，但是要裝依賴 A 的包 B，爲了滿足依賴關係必須重新安裝 A 。

就好比一棵依賴樹，一般的包管理器是樹根動了就會牽動樹枝樹葉，反過來樹葉動了不會動樹根，到了 cabal 這邊樹葉動了有可能樹根也得動，然後就牽一髮則動全身，到頭來整個系統裏所有包都得重新裝一遍的可能性不小。

3. cabal 只管裝，不管刪

意思很明白不用多解釋了吧，這也是很多人說 cabal 不是包管理器的原因之一，因爲它只管一半啊。

其實很多問題都不是 cabal 自己的問題，而是 Haskell 作爲靜態編譯型語言卻沒有穩定的 ABI 模型和鏈接模型的問題。這另一方面可能反應了 Haskell 一句座右銘「做一切努力避免成功(avoid success at all costs)」。當然這句話是有其解釋的：

I mentioned this at a talk I gave about Haskell a few years back and it』s become quite widely quoted. When a language becomes too well known, or too widely used and too successful suddenly you can』t change anything anymore. You get caught and spend ages talking about things that have nothing to do with the research side of things. Success is great, but it comes at a price. -- Simon Peyton Jones

換句話說，作爲一個學術研究目的的語言，如果 Haskell 一旦成功到大範圍使用，成功到要努力考慮向後兼容性，成功到要保持穩定 ABI/API 的程度，那它就不那麼容易接納新的變化了，這是成功帶來的代價（C++社區正在努力償還這個代價然後從古典C++走向現代C++）。爲了避免這種代價，隨時擁抱變化，Haskell就形成了這種「不穩定」的特點，而這一特點造成的麻煩就集中體現在了它的包管理器 cabal 身上。

最後再說一句，提這個不是爲了引戰， Haskell 是個非常好的語言，提供了非常多新穎的特點，haskell 社區是一個網聚了諸多智慧大牛的地方，cabal 也是不斷成熟的框架，在努力克服和避免上述（和沒有提到的）問題。（求輕噴）

請題主先說幾個比 npm 更好的包管理器讓我們學習一下。

Windows / Android 上的XX電腦管家啥的？

npm缺點肯定有很多,要不也不會這麼多人抱怨.,所以沒什麼不好意思承認.

不過樓主可以將npm的缺點說的具體點,因為可能你認為的缺點很多人有其它的解決方案甚至於不同意見.

另外,包管理器本身確實比較複雜難做好,這是客觀事實,不妨參考眾多已死或者正在死去的各種包管理器.

還有就是有比無要好.如果沒有npm雖然沒有抱怨,但是你的生產力會因此而提高還是下降呢?

最後就像 @Yi Kai 說的:

世界上只有兩種包管理工具，被人罵的和沒人用的。

這話可以套用在任何流行的技術上,比如Java.

有啊，國產Android上大部分應用市場。

npm不知道比他們高到哪裡去了。

必須蘋果的 Mac App Store 。

（有人說國內的安卓應用商店，哎，怎麼說，在他們面前mac就是個殘廢。）

首先，你要註冊個蘋果帳號才能用。

其次，你千辛萬苦註冊好了，下載應用的時候還要讓你輸賬戶密碼，收費的應用也就罷了，免費的應用也得輸密碼！（新版本裡面免費的終於不用輸密碼了。。。）

再次好容易你不嫌麻煩的輸了密碼，結果提示密碼錯誤。。。（因為你上一次輸密碼的時候是N月以前），然後你還得找回密碼，如果你的郵箱是你常用的郵箱還好，不幸的是我綁了gmail，所以我找回密碼還得翻牆

千辛萬苦翻了牆，發現我的gmail密碼給忘了。。。。。

在我堅韌不拔的找回了gmail的密碼後，然後再重置蘋果賬戶密碼，然後再點擊下載輸入密碼後，這時候你發現下載不下來，蘋果Mac App Store的伺服器又抽風連不上了。。。。

最後的最後，我去網上下載個應用裝上去了。

世界上只有兩種包管理工具，被人罵的和沒人用的。

看來你是沒用過 homebrew

Maven...

cocoapods 不服

我想說 rnpm……

聽說過FreeBSD上的Package嗎？

沒有了，規範一坨屎，實現一坨屎。

先說規範：

npm沒有命名空間，所以各種奇葩的命名以及搶注行為。因為沒有命名空間，所以每次安裝依賴包都要花N長時間，體驗極差，好像現在有個scope了，但是還遠遠沒有普及，幾乎如同沒有。
定義依賴也是一個奇葩，原本能寫死版本的非要搞一個表達式，更重要的是大部分的NPM包也都是用表達式來定義依賴，這導致每次安裝可能都不一樣，也許在你機器上能成功運行但在別人那就會失敗，而且沒有人知道發生了什麼變化。寫死版本則不會有這個問題。
依賴傳遞也是如此，遇到了好幾次，因為依賴包版本衝突，每個版本都存在遇你的node_modules，你完全不知道它會以什麼樣的邏輯運行哪個版本，如果知道某個版本確定有問題，如何統一的全局去覆蓋，並不能做到。

算了，無力吐槽~心累

fdupdate

pakke

我就是來看看有幾個人能get到難用點的。。。

npm還不好？

每次我npm install之後就會去看看遠處，做做肩頸放鬆訓練，看輪子哥逛知乎。

現在眼不花了，脖子不酸了，一口氣能上5層樓。

其它包管理器能有這功效？

感謝npm!

我的感覺是，折騰各種包管理工具本身會浪費不少時間，尤其是國內環境下

有時候npm半天不影響，bower一下沒動靜，composer就更爛了，還不如自己去官方地址直接download

題主不應該先舉證自己的觀點，再來問嗎？

這類的問題，有個統一的格式可以回答：「世界上有兩種XXX，一種是被人們天天罵的，一種是根本沒人用的」。這個回答格式可以輕鬆回答以下問題：

「還有比Java更差勁的語言嗎？」

「還有比Python更差勁的語言嗎？」

「還有比Maven更差勁的包管理器嗎？」

「還有比pip更差勁的包管理器嗎？」

「還有比AngularJS更差的前端架構嗎？」

「還有比Backbone更差的前端架構嗎？」

「還有比React/Flux更差的前端架構嗎？」

以及

「PHP是最好的語言嗎？」

國內的安卓市場版本各種不一致要是裝多了就會這個市場升級了那個市場又提示你要升級。

pip啊