读懂package.json -- 依赖管理

fyber 发布于2019-08-20 17:32 / 2775人阅读

摘要：做为项目的包管理工具，由于其与的紧密配合和出自一人之手，目前已经基本没有竞争对手。依赖树不同于很多语言的依赖管理，使用的是依赖树。潜在的运行时冲突。希望以上的介绍能够帮助你更好的理解的依赖管理。

npm做为Javascript项目的包管理工具，由于其与Node.js的紧密配合（npm和Node.js出自一人之手），目前已经基本没有竞争对手。

包管理工具要解决的主要问题就是依赖包的安装，在Javascript项目中，包的依赖关系是由package.json给出的，这篇文件将介绍package.json中描述的依赖信息。

依赖管理

在package.json中，有如下几项涉及到依赖包的描述：

dependencies

 项目中使用到的包，但不包括测试所使用的包

devDependencies

主要是在测试时使用的包，也包括一些代码编译的包，比如将coffee-script编译为javascript。也就是说在仅仅使用该项目的时候（而不进行测试等环节），不需要安装的包可以放在devDependencies中

peerDependencies

如果改项目需要指明一些有协作关系的包的版本时，使用peerDependencies。这里使用了协作，而不是依赖，是我个人的理解。peerDependencies并不是必须安装的包，但如果一旦要安装，就要符合要求。比如react-dom的package.json中有如下的描述：

"peerDependencies": {
    "react": "^15.6.1"
   },

peerDependencies至少打消了一些顾虑，比如react生态中用到的一些包在升级的时候会不会不匹配？

optionalDependencies

如果有一些依赖包即使安装失败，项目仍然能够运行或者希望npm继续运行，就可以使用optionalDependencies。另外optionalDependencies会覆盖dependencies中的同名依赖包，所以不要在两个地方都写。

bundledDependencies/bundleDependencies

如果在打包发布的使用希望一些依赖包也出现在最终的包里，那么可以将包的名字放在bundledDependencies，bundledDependencies的值是一个字符串数组，如：

"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时，renderized 和super-streams也会被一同安装。

这些项的内容形式都是一样的(除了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就是项目的名词，而value可以有多种形式

version，遵循semver

一个tarball的url

一个git url

本地路径

关于semver会在另一篇文章中介绍（先挖个坑）。

依赖树

不同于很多语言的依赖管理，npm使用的是依赖树。也就是说每个依赖包会有一套自己指定的（在package.json中说明的）依赖包，而不会和其他包共享。
例如，mod-a依赖mod-b@1.0.0，mod-c依赖mod-b@2.0.0，而现在有一个项目依赖mod-a和mod-c，那么最终安装的依赖包如下：

├─┬ node_modules
│ ├─┬ mod-a
│ │ ├── mod-b@1.0.0
│ ├─┬ mod-c
│ │ ├── mod-b@2.0.0

而Node.js在加载依赖包的时候会处理这个问题。之所以文章最开始说npm和Node.js的紧密合作也是这个原因。

使用依赖树来管理包带来了一个明显的好处，不用处理依赖冲突的问题。这个问题在早期的Java项目中比较常见，而在使用了Maven和Gradle之后，情况有所缓解，但只能减轻同一个包多个版本被放入发布的包中这种情况，仍然无法解决依赖冲突这个根本问题。

依赖树也有一些缺点：

代码量增加。由于不能共享相同的包（在npm v3中，尝试着共享相同版本的库，但还是比较弱），导致最终打包的时候有同一个库的多个版本的代码出现在最终包中。

潜在的运行时冲突。以上面的例子为例，可能有些时候，mod-b的两个版本无法同时运行，而这只有在运行或者测试的时候才能被发现。

希望以上的介绍能够帮助你更好的理解npm的依赖管理。

GPU云服务器云服务器 package.json 依赖管理工具读懂sql 零基础读懂云计算

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/83668.html

读懂ES7中javascript修饰器

摘要：例子修饰类自定义参数值此例和上面功能基本一致，唯一差别在于值是参考修饰函数传过来的例子修饰方法修饰函数，对方法进行只读操作尝试修改函数，在控制台会报错上例中，我们对类中的方法使用修饰器进行修饰，使得方法不能被修改。什么是修饰器修饰器（Decorator）是ES7的一个提案，它的出现能解决两个问题：不同类间共享方法编译期对类和方法的行为进行改变用法也很简单，就是在类或方法...

kelvinlee 2019-08-21 16:56 评论0 收藏0
从react-start到co源码(二)

摘要：第三篇脚手架依赖的核心库的源码解析。这三篇文章都是我在日常学习中总结出来的，文章中涉及到的所有代码可以从我的上找到。 react作为当前十分流行的前端框架，相信很多前端er都有蠢蠢欲动的学习它的想法。工欲善其事，必先利其器。这篇文章就简单的给大家介绍一下如何我快速的搭建一个react前端开发环境。主要针对于react小白，大神不喜勿喷。从标题可以看出，这里不会仅仅只介绍一下react的...

MockingBird 2019-08-20 13:46 评论0 收藏0
Yarn 构建工具入门基础

摘要：就是一个类似于的包管理工具，它是由推出并开源。二的安装用法和基本工作流安装以为例你可以通过包管理工具安装。在使用一个包之前，你需要执行以下命令将其加入依赖项列表会被加入到文件中的依赖列表，同时也会被更新。一、yarn的背景和介绍一直以来，我们在安装和管理依赖的时候基本上都会使用npm，npm是一个非常优秀全面且广受欢迎的包管理工具，它奠定了前端模块化开发的基石，为前端的发展做出了不可...

tuniutech 2019-08-23 11:58 评论0 收藏0
你想知道关于package-lock.json的一切，但是太害怕了问了？

摘要：内容结构是中列出的每个依赖项的大型列表，应安装的特定版本，模块的位置，验证模块完整性的哈希，它需要的包列表，以及依赖项列表。期望与真实行为之间的这种冲突在中引发了一个非常有趣的问题线索。此更改是作为的一部分发布的，该版本于年月日上线。 showImg(https://segmentfault.com/img/bVbkuXN?w=1440&h=1080); 想阅读更多优质文章请猛戳Git...

OBKoro1 2019-08-02 12:11 评论0 收藏0