主要是探讨不同依赖配置对项目的影响1.devDependencies添加devDependencies依赖的方式npminstall--save-dev//缩写npmi-D这个配置项放置了本地开发过程中需要用到的编译、打包、测试、格式化模块等。安装依赖时，不会安装依赖的devDependencies。2.dependencies添加依赖的方式是npminstall//简称npmi在项目实际运行中需要用到的代码，如果没有就会报错1.唯一的依赖例如：faker-project项目依赖于sdk-a//faker-project{"name":"faker-project","dependencies":{"sdk-a":"1.0.0"}}sdk-a的依赖包括sdk-core//sdk-a{"name":"sdk-a","version":"1.0.0","dependencies":{"sdk-core":"0.0.1"}}然后faker-project执行npminstall后，目录结构如下：fakerproject|├──node_modules|├──sdk-a|└──sdk-core|└──package.json所有的依赖都将设置在同一层2。重复依赖2.1不兼容假设faker-project再次依赖sdk-b//faker-project{"name":"faker-project","dependencies":{"sdk-a":"1.0.0",+"sdk-b":"1.0.0"}}而sdk-b正好依赖sdk-core，只是sdk-core的版本不同//sdk-b{"name":"sdk-b","version":"1.0.0","dependencies":{"sdk-core":"0.0.2"}}然后faker-project执行npminstall后，目录结构如下：fakerproject|├──node_modules|├──sdk-a+|├──sdk-b+||└──node_modules+||└──sdk-core//0.0.2+|||└──sdk-core//0.0.1|└──package.json依赖会单独安装在自己的node_modules中，避免冲突2.2如果sdk-core版本兼容则兼容//sdk-a{"name":"sdk-a","version":"1.0.1","dependencies":{-"sdk-core":"0.0.1"+"sdk-core":"^0.0.1"}}那么两者将共享一个fakerproject|├──node_modules|├──sdk-a|├──sdk-b|└──sdkdependency(先安装一个再安装另一个，最终目录结构会一致不兼容)-core//0.0.2|└──package.json3.在npm3之前，不会横向设置node_modules，直接嵌套依赖，在代码库中，表示宿主环境需要提供moduled该配置下的依赖项，与宿主环境密切相关。npm（3.x版本之后，7.x版本之前），yarn在这个配置下不会自动安装依赖的模块，并且会警告你。时间节点：npm3-2015年5月npm5-2017年5月yarn1-2017年9月yarn2-2020年1月npm7-2021年3月PS：为了便于理解，下图：新版本：npm7及以上版本会自动安装peerDependencies旧版本：npm3.x~6.x和yarn不会自动安装peerDependencies1。唯一的依赖//sdk-a{"name":"sdk-a","version":"1.0.2","peerDependencies":{"sdk-core":"^0.0.1"}}旧的1.1版本不会自动安装此配置下的依赖模块，并会警告你。用户需要安装警告“>sdk-a@1.0.3”具有未满足的对等依赖性“sdk-core@^0.0.1”。伪造者项目|├──节点模块|└──sdk-a|└──包。新版的json1.2会自动安装，永远只有一个。直接下node_modules1.3区别无论是自动还是手动，最后的结果都是一样的。peerDependencies中的依赖会直接安装在node_modules下，最大的区别是老版本是手动安装的。它会体现在项目的依赖中，但是新版本不会//??faker-project{"name":"faker-project","dependencies":{"sdk-a":"1.0.3","sdk-core":"^0.0.1"//最大的区别}}2.重复依赖2.1不兼容2.1.1老版本只会提示不同版本对端依赖信息warning">sdk-a@1.0.4"hasunmetpeerdependency"sdk-core@0.0.1".warning">sdk-b@1.0.2"hasunmetpeerdependency"sdk-core@0.0.2".2.1.2新版本有不兼容的依赖，安装时会直接报错。您可以通过--legacy-peer-deps使peerDependencies不自动安装。2.1.3如何处理不兼容的peerDependencies目前还没有办法让不兼容的peerDependencies生效。所以当出现这种情况时，一般的解决办法是修改其中一个有peerDependencies依赖的包版本。让它依赖另一个版本的peerDependencies和其他兼容2.2的版本//sdk-b{"name":"sdk-b","version":"1.0.3","peerDependencies":{"sdk-core":"^0.0.1"}}//faker-project{"name":"faker-project","dependencies":{"sdk-a":"1.0.4","sdk-b":"1.0.3"}}多个项目兼容peerDependencies2.2.1老版本不自动安装，只提示2.2.2自动安装新版本，与唯一依赖行为相同2.3特殊情况下，如果sdk-core,peerDependencies和dependencies都存在当2.3.1旧版本不会安装时，相当于只安装peerDependencies2.3.2新版本会自动安装，相当于只有dependencies两种情况下，它没有判断版本兼容2.4嵌套依赖的极端情况比较多，比如dependencies如果有peerDependencies。有关详细信息，请参阅以下文章。4.总结运行时没有用到的依赖，将插件类的依赖放在devDependencies中（比如sdk-core是一个依赖，在此基础上开发的依赖有sdk-a和sdk-b).使用peerDependencies需要在运行时有单例依赖（vue、react等只能同时存在一个实例）。使用peerDependencies其余使用依赖5.其他依赖其他比较少见的依赖1.optionalDependenciesoptionalDependencies可选依赖，如果有一些依赖包即使安装失败，项目仍然可以运行或者想要npm继续运行，可以使用optionalDependencies。另外optionalDependencies会覆盖dependencies中的同名依赖，所以不要两处都写。例如，一个可选的依赖包就像一个程序插件。如果存在，则执行已有的逻辑，如果不存在，则执行另一个逻辑。.try{varfoo=require('foo')varfooVersion=require('foo/package.json').version}catch(er){foo=null}if(notGoodFooVersion(fooVersion)){foo=null}//..然后后面在你的程序中..if(foo){foo.doFooThings()}2.bundledDependencies/bundleDependencies包依赖，bundledDependencies是一个包含依赖包名的数组对象，这个对象中的包会在发布到最终时被打包发布包。如：{"name":"fe-weekly","description":"ELSEWeekly","version":"1.0.0","main":"index.js","devDependencies":{"fw2":"^0.3.2","grunt":"^1.0.1","webpack":"^3.6.0"},"dependencies":{"gulp":"^3.9.1","hello-else":"^1.0.0"},"bundledDependencies":["fw2","hello-else"]}执行打包命令npmpack，在生成的fe-weekly-1.0.0.tgz包中，包含fw2和hello-else。但值得注意的是，这两个包必须先在devDependencies或dependencies中声明，否则包会报错。参考几种你需要知道的npm依赖包管理——https://zhuanlan.zhihu.com/p/29855253
