資訊專欄INFORMATION COLUMN
摘要：做為項(xiàng)目的包管理工具，由于其與的緊密配合和出自一人之手，目前已經(jīng)基本沒有競爭對手。依賴樹不同于很多語言的依賴管理，使用的是依賴樹。潛在的運(yùn)行時(shí)沖突。希望以上的介紹能夠幫助你更好的理解的依賴管理。
npm做為Javascript項(xiàng)目的包管理工具，由于其與Node.js的緊密配合（npm和Node.js出自一人之手），目前已經(jīng)基本沒有競爭對手。
包管理工具要解決的主要問題就是依賴包的安裝，在Javascript項(xiàng)目中，包的依賴關(guān)系是由package.json給出的，這篇文件將介紹package.json中描述的依賴信息。
依賴管理在package.json中，有如下幾項(xiàng)涉及到依賴包的描述：
dependencies
項(xiàng)目中使用到的包，但不包括測試所使用的包
devDependencies
主要是在測試時(shí)使用的包，也包括一些代碼編譯的包，比如將coffee-script編譯為javascript。也就是說在僅僅使用該項(xiàng)目的時(shí)候（而不進(jìn)行測試等環(huán)節(jié)），不需要安裝的包可以放在devDependencies中
peerDependencies
如果改項(xiàng)目需要指明一些有協(xié)作關(guān)系的包的版本時(shí)，使用peerDependencies。這里使用了協(xié)作，而不是依賴，是我個(gè)人的理解。peerDependencies并不是必須安裝的包，但如果一旦要安裝，就要符合要求。比如react-dom的package.json中有如下的描述：
"peerDependencies": {
"react": "^15.6.1"
},
peerDependencies至少打消了一些顧慮，比如react生態(tài)中用到的一些包在升級的時(shí)候會不會不匹配？
optionalDependencies
如果有一些依賴包即使安裝失敗，項(xiàng)目仍然能夠運(yùn)行或者希望npm繼續(xù)運(yùn)行，就可以使用optionalDependencies。另外optionalDependencies會覆蓋dependencies中的同名依賴包，所以不要在兩個(gè)地方都寫。
bundledDependencies/bundleDependencies
如果在打包發(fā)布的使用希望一些依賴包也出現(xiàn)在最終的包里，那么可以將包的名字放在bundledDependencies，bundledDependencies的值是一個(gè)字符串?dāng)?shù)組，如：
"name": "awesome-web-framework",
"version": "1.0.0",
"bundledDependencies": [
"renderized", "super-streams"
]
npm pack會將renderized 和super-streams放入生成的包awesome-web-framework-1.0.0.tgz中，并且在npm install awesome-web-framework-1.0.0.tgz時(shí)，renderized 和super-streams也會被一同安裝。
這些項(xiàng)的內(nèi)容形式都是一樣的(除了bundledDependencies)，只是作用不同，如：
"dependencies": {
"base62": "~0.1.1",
"commoner": "~0.7.0",
"esprima": "https://github.com/facebook/esprima/tarball/ca28795124d45968e62a7b4b336d23a053ac3a84",
"recast": "~0.4.8",
"source-map": "~0.1.22"
}
key就是項(xiàng)目的名詞，而value可以有多種形式
version，遵循semver
一個(gè)tarball的url
一個(gè)git url
本地路徑
關(guān)于semver會在另一篇文章中介紹（先挖個(gè)坑）。
依賴樹不同于很多語言的依賴管理，npm使用的是依賴樹。也就是說每個(gè)依賴包會有一套自己指定的（在package.json中說明的）依賴包，而不會和其他包共享。
例如，mod-a依賴[email protected]，mod-c依賴[email protected]，而現(xiàn)在有一個(gè)項(xiàng)目依賴mod-a和mod-c，那么最終安裝的依賴包如下：
├─┬ node_modules │ ├─┬ mod-a │ │ ├── [email protected] │ ├─┬ mod-c │ │ ├── [email protected]
而Node.js在加載依賴包的時(shí)候會處理這個(gè)問題。之所以文章最開始說npm和Node.js的緊密合作也是這個(gè)原因。
使用依賴樹來管理包帶來了一個(gè)明顯的好處，不用處理依賴沖突的問題。這個(gè)問題在早期的Java項(xiàng)目中比較常見，而在使用了Maven和Gradle之后，情況有所緩解，但只能減輕同一個(gè)包多個(gè)版本被放入發(fā)布的包中這種情況，仍然無法解決依賴沖突這個(gè)根本問題。
依賴樹也有一些缺點(diǎn)：
代碼量增加。由于不能共享相同的包（在npm v3中，嘗試著共享相同版本的庫，但還是比較弱），導(dǎo)致最終打包的時(shí)候有同一個(gè)庫的多個(gè)版本的代碼出現(xiàn)在最終包中。
潛在的運(yùn)行時(shí)沖突。以上面的例子為例，可能有些時(shí)候，mod-b的兩個(gè)版本無法同時(shí)運(yùn)行，而這只有在運(yùn)行或者測試的時(shí)候才能被發(fā)現(xiàn)。
希望以上的介紹能夠幫助你更好的理解npm的依賴管理。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/83668.html
摘要：例子修飾類自定義參數(shù)值此例和上面功能基本一致，唯一差別在于值是參考修飾函數(shù)傳過來的例子修飾方法修飾函數(shù)，對方法進(jìn)行只讀操作嘗試修改函數(shù)，在控制臺會報(bào)錯上例中，我們對類中的方法使用修飾器進(jìn)行修飾，使得方法不能被修改。 什么是修飾器 修飾器（Decorator）是ES7的一個(gè)提案，它的出現(xiàn)能解決兩個(gè)問題： 不同類間共享方法 編譯期對類和方法的行為進(jìn)行改變 用法也很簡單，就是在類或方法...
摘要：第三篇腳手架依賴的核心庫的源碼解析。這三篇文章都是我在日常學(xué)習(xí)中總結(jié)出來的，文章中涉及到的所有代碼可以從我的上找到。 react作為當(dāng)前十分流行的前端框架，相信很多前端er都有蠢蠢欲動的學(xué)習(xí)它的想法。工欲善其事，必先利其器。這篇文章就簡單的給大家介紹一下如何我快速的搭建一個(gè)react前端開發(fā)環(huán)境。主要針對于react小白，大神不喜勿噴。從標(biāo)題可以看出，這里不會僅僅只介紹一下react的...
摘要：就是一個(gè)類似于的包管理工具，它是由推出并開源。二的安裝用法和基本工作流安裝以為例你可以通過包管理工具安裝。在使用一個(gè)包之前，你需要執(zhí)行以下命令將其加入依賴項(xiàng)列表會被加入到文件中的依賴列表，同時(shí)也會被更新。 一、yarn的背景和介紹一直以來，我們在安裝和管理依賴的時(shí)候基本上都會使用npm，npm是一個(gè)非常優(yōu)秀全面且廣受歡迎的包管理工具，它奠定了前端模塊化開發(fā)的基石，為前端的發(fā)展做出了不可...
摘要：內(nèi)容結(jié)構(gòu)是中列出的每個(gè)依賴項(xiàng)的大型列表，應(yīng)安裝的特定版本，模塊的位置，驗(yàn)證模塊完整性的哈希，它需要的包列表，以及依賴項(xiàng)列表。期望與真實(shí)行為之間的這種沖突在中引發(fā)了一個(gè)非常有趣的問題線索。此更改是作為的一部分發(fā)布的，該版本于年月日上線。 showImg(https://segmentfault.com/img/bVbkuXN?w=1440&h=1080); 想閱讀更多優(yōu)質(zhì)文章請猛戳Git...
閱讀 783·2023-04-25 20:47
閱讀 2551·2019-08-30 15:53
閱讀 959·2019-08-26 14:05
閱讀 905·2019-08-26 11:59
閱讀 1692·2019-08-26 11:43
閱讀 1693·2019-08-26 10:57
閱讀 1366·2019-08-23 18:23
閱讀 2684·2019-08-23 12:57
