npm如何工作
假设依赖格式package{dep}, 那么 A{B,C}, B{C}, C{D} 安装后。
1 | A |
A的依赖让C提到了和B同级,而不是在B的下一级。而D被提到B,C同级,是因为npm管理会在没有冲突的前提下,尽量将依赖提升到较高层级。(扁平化)
有冲突实例:
A{B,C}, B{C,D@1}, C{D@2}
1 | A |
对于 npm 来说同名但不同版本的包是两个独立的包,而同层不能有两个同名子目录,所以其中的 D@2 放到了 C 的子目录而另一个 D@1 被放到了再上一层目录。
npm 5+ package-lock.json
package-lock 结构是同样类型的几个字段嵌套起来的, version, resolved, integrity, requires, dependencies 这几个字段而已。
version 准确版本号
resolved 安装源的
integrity 内容hash
dependencies: 层次结构与文件系统中 node_modules 的文件夹层次结构是完全对照的
requires: 除最外层的 requires 属性为 true 以外, 其他层的 requires 属性都对应着这个包的 package.json 里记录的自己的依赖项
1 | { |
版本管理
如果本地 node_modules 已安装,再次执行 install 不会更新包版本, 执行 update 才会更新; 而如果本地 node_modules 为空时,执行 install/update 都会直接安装更新包;
如果package.json 指定某个依赖 ^1.0.0 , 无论后面执行 npm install 还是 update, package.json 都会安装不超过2.0.0最新的包。
package-lock
无论何时执行 install, npm 都会优先按照 package-lock 中指定的版本来安装;
无论何时完成安装/更新, package-lock 文件总会跟着 node_modules 更新 —— (因此可以视 package-lock 文件为 node_modules 的 JSON 表述)
已安装 node_modules 后若执行 npm update,package.json 中的版本号也会随之更改为 ^1.15.0
升级依赖包
升级小版本: 本地执行 npm update 升级到新的小版本
升级大版本: 本地执行 npm install
@ 升级到新的大版本 也可手动修改 package.json 中版本号为要升级的版本(大于现有版本号), 然后执行 npm install本地验证升级后新版本无问题后
降级依赖包
正确: npm install
@ 验证无问题后 错误: 手动修改 package.json 中的版本号为更低版本的, 这样修改并不会生效,因为再次执行 npm install 依然会安装 package-lock.json 中的锁定版本
删除依赖包
npm uninstall
把要卸载的包从 package.json 中 dependencies 字段删除, 然后执行 npm install
有人提交了 package.json, package-lock.json,其他成员应在git pull后执行 npm install 脚本安装更新后的依赖包
npm 配置
npm config 通过 npm config ls -l 可查看npm的所有配置,包括默认配置。文档
查看某个配置的命令为 npm config get
修改配置的命令为 npm config set
删除指定的配置项命令为 npm config delete
registry 指定npm下载安装包时的源,默认为 https://registry.npmjs.org/(发布npm时,如果电脑按转cnpm会修改这项配置)
package-lock 是否默认生成 package-lock 文件
npmrc文件
通过 npmrc 文件同样可以直接修改配置,优先级由高到低包括地址:
工程内配置文件: /path/to/my/project/.npmrc
用户级配置文件: ~/.npmrc
全局配置文件: $PREFIX/etc/npmrc
npm内置配置文件: /path/to/npm/npmrc