tp5手机网站开发,怎么开网店需要多少钱,旅游网站设计模板图片,百度收录查询接口大家好#xff0c;我是若川。今天给大家推荐一篇关于 npm install 的好文。很快能看完。点击下方卡片关注我、加个星标学习源码整体架构系列、年度总结、JS基础系列前言项目中执行npm install发生了什么#xff0c;众所周知#xff0c;执行npm install时会在当前项目目录的n… 大家好我是若川。今天给大家推荐一篇关于 npm install 的好文。很快能看完。点击下方卡片关注我、加个星标学习源码整体架构系列、年度总结、JS基础系列前言项目中执行npm install发生了什么众所周知执行npm install时会在当前项目目录的node_modules中安装依赖。并且将依赖项的层级关系保存在package-lock.json中。那么依赖项的层级关系是怎么确认的依赖项之间是否存在区别有无package-lock.json在安装时有什么区别呢笔者希望借以此文可以和读者们一起厘清npm install。工欲善其事必先利其器先一起来了解下npm install。npm-install常用的命令包含具体含义和执行效果会在下文说明npm installnpm install -P|--save-prodnpm install -D|--save-devnpm install -O|--save-optionalnpm install --no-savealiases: npm i, npm addnpm install这个命令会在项目路径下安装一个或多个依赖包如果项目中存在package-lock、npm-shrinkwrap或yarn.lock文件。那么安装过程将就基于这些文件。其优先级为:npm-shrinkwrap.jsonpackage-lock.jsonyarn.lock其中npm-shrinkwrap.json是npm 5之前的依赖锁定文件其在npm 5后被package-lock.json替换。两个文件功能类似最大的不同是npm-shrinkwrap.json需要执行npm shrinkwrap来初始化生成而package-lock.json为自动生成。本文撰写时npm使用的版本为v6.14.5故下文所有样例均在此版本下做交流讨论。其他版本任何问题欢迎留言讨论。yarn.lock是yarn cli的产物不在此文章讨论。npm install执行时会解析package.json中定义的依赖关系进而根据package.json生成package-lock.json依赖锁定文件。package.json中的依赖关系可以由开发人员自行定义也可使用npm install [--optional]来指定存储位置或使用npm install --no-save不进行存储。自古习物先习源。package.json中是那些在影响依赖树呢package.jsonpackage.json文件是项目的描述文件包括项目的name、version、description等很多字段。但真正影响依赖树的并不多包括dependencies、devDependencies 、peerDependencies、 optionalDependencies 、bundledDependencies。下面一起来看下他们区别和使用场景。dependencies主要依赖dependencies是主要依赖。也即必须依赖。由包名和版本区间映射成的简单 json对象组成。版本区间由一个或多个分隔符组成。是项目运行、打包的主要依赖。执行npm install时会从上至下递归安装dependencies及其内部依赖。并将解析的依赖树存储在package-lock.json中。会随版本一起发布到npm库。是最重要的依赖节点。执行npm install -P|--save-prod会将指定包放入此节点。常用的dependencies如axios、fetch等。{dependencies: {axios: ^0.21.1,fetch: ^1.1.0}
}
devDependencies开发依赖devDependencies是开发环境的依赖。其格式同dependencies开发人员本地执行npm install时也会从上至下递归安装devDependencies及其内部依赖。并将解析的依赖树存储在package-lock.json中。也会随版本一起发布到npm库。但是不同的是。非开发人员通过项目安装依赖时。也就是包安装后出现在node_modules中时devDependencies不会被安装也不会出现在项目的package-lock.json中。所以在开发时dependencies和devDependencies区别并不大但是作为依赖包被其他项目引入时只有dependencies中的依赖会被解析成依赖树并下载。devDependencies中的依赖会被忽略。执行npm install -D|--save-dev会将指定包放入此节点。常用的devDependencies如karma、mocha、webpack等{devDependencies: {karma: ^1.3.0,mocha: ^5.2.0,webpack: ^1.13.1,webpack-dev-server: ^1.14.1}
}
peerDependencies同等依赖peerDependencies是同等依赖。其格式同dependencies。主要在开发包时使用常规开发项目不建议使用。比如某些情况下开发人员为了表明在不同系统和运行环境下的兼容性即非所有情况下都是必要的依赖。就会通过peerDependencies来表明。peerDependencies中更像是当前包所依赖是插件。peerDependencies里面的依赖会随版本一起发布但是不会自动安装需要开发和使用人员手动安装。npm v7下会默认安装如eslint-plugin-prettier会同等依赖eslint和prettier。即eslint-plugin-prettier需要在eslint和prettier都安装时才会生效。但是其自身并不会强制安装eslint和prettier。而是会通过警告的方式提示开发者。eslint-plugin-prettier requires a peer of xxx but none is installed. You must install peer dependencies yourself如果不想在未安装peerDependencies的情况下提示警告。可以通过peerDependenciesMeta设置optional为true来关闭警告。{peerDependencies: {eslint: 5.0.0,prettier: 1.13.0},peerDependenciesMeta: {eslint: {optional: true}}
}
optionalDependencies可选依赖optionalDependencies是可选依赖。其格式同dependencies。当需要某些依赖在安装失败时不会阻塞项目的运行和打包就可以使用optionalDependencies来定义。optionalDependencies里面的依赖会随版本一起发布且会自动安装。可以使用npm install --no-optional命令来跳过安装。执行npm install -O|--save-optional会将指定包放入此节点。optionalDependencies使用需要开发者在项目中作兼容。如try {var foo require(foo)var fooVersion require(foo/package.json).version
} catch (er) {foo null
}if ( notGoodFooVersion(fooVersion) ) {foo null
}// .. then later in your program ..if (foo) {foo.doFooThings()
}
bundledDependencies绑定依赖bundledDependencies是绑定依赖其值是一个数组。在发包时定义绑定包。常规项目中使用的并不多。和npm install的也并无关系所以在此不做过多介绍。值得一提的是使用bundleDependencies也是可以的。{name: awesome-web-framework,version: 1.0.0,bundledDependencies: [renderized,super-streams]
}
了解了package.json中影响依赖树的节点那么接下来就是重头戏npm install登场了~一、无依赖冲突最简单的场景莫过于此当项目的package.json的依赖及其子 依赖间没有冲突时即A依赖B、C、D。表示为A[B、C、D]。则依赖会平铺在node_modules下。即使有多个相同的依赖只要版本不存在冲突就都符合当前场景。举个例子。fetch-demo2项目中值依赖fetch这一个包。{name: fetch-demo2,version: 1.0.0,description: ,main: index.js,dependencies: {fetch: ^1.1.0},devDependencies: {},scripts: {test: echo \Error: no test specified\ exit 1},keywords: [],author: ,license: ISC
}
此时执行npm i会得到如下的目录结构的node_modules。可得到依赖树根据package-lock.json分析得出不难得出以下结论。当项目中的依赖无冲突时项目依赖及其内部依赖会平铺在一级node_modules中。二、项目顶级依赖存在冲突顶级依赖即项目package.json中的依赖。当项目顶级依赖存在冲突时会将顶级依赖放在node_modules中的一级目录下冲突的包放在自己的node_modules下。为了模拟这种场景将biskviit2.0.0放在fetch-demo2项目的顶级依赖上。{dependencies: {fetch: ^1.1.0,biskviit: 2.0.0}
}
执行npm install后查看node_modules的目录结构分析依赖树可以看出在顶级依赖biskviit2.0.0和内部依赖biskviit1.0.1存在冲突时顶级依赖会占据node_modules的一级目录内部依赖则会存储在其内部的node_modules中三、项目内部依赖存在冲突当项目的内部依赖存在冲突时会先检测一级node_modules是否存在依赖包不存在则存储如果存在判断是否有版本冲突无冲突则使用一级node_modules的依赖包有冲突则存储在自身的node_modules中。还是举例说明下。一级node_modules无冲突包发布自定义新包conflict-lbywer1.0.0到npm。其依赖为{dependencies: {biskviit: ^2.0.0}
}
将fetch-demo2项目的顶级依赖改为{dependencies: {conflict-lbywer: 1.0.0,fetch: ^1.1.0}
}
删除node_modules和package-lock.json后执行npm i后查看目录结构分析依赖树可以看出conflict-lbywer所依赖的biskviit2.0.0和fetch所依赖的biskviit1.0.1冲突时在顶级依赖没有biskviit的情况下将biskviit2.0.0安装到了顶级依赖。如果将顶级依赖中的conflict-lbywer和fetch更换顺序呢依赖包顺序是否会发生变化我们一起来研究。修改顶级依赖{dependencies: {fetch: ^1.1.0,conflict-lbywer: 1.0.0}
}
删除node_modules和package-lock.json后执行npm i后查看目录结构分析依赖树可以看出在调整conflict-lbywer和fetch顺序后目录结构并无变化。所以可得出结论在一级node_modules不存在冲突包时会将高版本的包放在一级node_modules中。低版本的放到内部的node_modules中。一级node_modules有冲突包如果一级node_modules有冲突包时情况又会如何呢删除顶级依赖中的conflict-lbywer{dependencies: {fetch: ^1.1.0}
}
删除node_modules和package-lock.json后执行npm i后查看目录结构分析依赖树顶级依赖添加conflict-lbywer1.0.0{dependencies: {fetch: ^1.1.0,conflict-lbywer: 1.0.0}
}
直接执行npm i后查看目录结构分析依赖树可以发现在依赖树无变化的情况下node_modules的目录结构是不一样的。所以可以得出结论在一级node_moudles已经存在依赖包的情况下新安装的依赖包如果存在冲突会安装到内部的node_modules中。四、存在package-lock.json这种情况也很简单npm install会完全按照package-lock.josn的层级结构下载安装依赖包删除node_moudles后执行npm install直接执行npm install后查看目录结构分析依赖树可以发现在存在package-lock.json的情况下node_modules的目录结构是稳定的。结语上文对执行npm install时一些常见的情况做了测试和分析也给出了相应的结论。欢迎读者们批评斧正。也欢迎打赏点赞哦~参考文献和链接https://docs.npmjs.com/cli/v7/commands/npm-installhttps://docs.npmjs.com/cli/v7/configuring-npm/package-jsonhttps://docs.npmjs.com/cli/v7/configuring-npm/folders最近组建了一个江西人的前端交流群如果你也是江西人可以加我微信 ruochuan12 拉你进群。今日话题略。欢迎分享、收藏、点赞、在看我的公众号文章~一个愿景是帮助5年内前端人走向前列的公众号可加我个人微信 ruochuan12长期交流学习推荐阅读我在阿里招前端我该怎么帮你可进模拟面试群2年前端经验做的项目没技术含量怎么办点击上方卡片关注我、加个星标················· 若川简介 ·················你好我是若川毕业于江西高校。现在是一名前端开发“工程师”。写有《学习源码整体架构系列》多篇在知乎、掘金收获超百万阅读。从2014年起每年都会写一篇年度总结已经写了7篇点击查看年度总结。同时活跃在知乎若川掘金若川。致力于分享前端开发经验愿景帮助5年内前端人走向前列。
