关于前端:npm相关知识点总结

5次阅读

共计 6782 个字符，预计需要花费 17 分钟才能阅读完成。

本文总结了工作中罕用到的以及一些不罕用容易疏忽的 npm 常识，包含:

npm 各种根本命令及作用
package.json 的各字段详解
版本号详解
npm3.x 装置依赖包的规定
对于 npm 源的解释与设置
pacak-lock.json 的解释与作用

形容	命令
查看 npm 版本	`npm -v`
初始化我的项目（生成 package.json）	`npm init`
查看所有全局装置的包	`npm list -g`
查看包的版本号	查看包的所有版本（近程） `npm view <Package Name> versions` 查看包的最新版本 `npm view <Package Name> version` 查看包的版本及其他信息 `npm info <Package Name> (在包文件夹下关上终端时能够间接输出 npm info)`
查看以后登陆的 npm 账号	`npm whoami`
登陆 npm	`npm login`
注册 npm	`npm adduser`
装置 pacakge.json 中的依赖包	`npm install`
装置第三方 npm 包	全局装置 `install <Package Name> -g` 本地装置 `npm install <Package Name>` 装置指定版本包 `npm install <Package Name>@xx.xx.xx` 装置最新版或 tag 版 `npm install <Package Name>@latest` `npm install <Package Name>@beta beta 为公布的 tag 版名称` 装置并写入 package.json 的 dependencies(生产环境依赖） `npm install <Package Name> --save` 装置并写入 package.json 的 devDepencies 中（开发环境依赖 `npm install <Package Name> --save-dev`
更新包	更新某个包 `npm update <Package Name>` 更新包的同时更新 package.json 文件中对应包的版本信息`npm update <Package Name> --save`
删除包	删除全局包 `npm uninstall <Package Name> -g` 删除包的同时删除留在 package.json 中 dependencies 下的包 `npm uninstall <Package Name> --save` 删除包的同时删除留在 package.json 中 devDependencies 下的包 `npm uninstall <Package Name> --save-dev`
批改源	`npm config set registry https://registry.npm.taobao.org` 查看源 `npm config get registry`
治理包作者	增加包作者 `npm owner add <user> <Package Name>` 删除包作者 `npm owner rm <user> <Package Name>` 查看包所有的作者 `npm owner ls <Package Name>` （owner 或 author 均可）
发包	在当前目录下关上终端公布正式版 `npm publish` 公布 tag 版（tag 名称随便） `npm publish --tag beta`
链接其余包当咱们本地开发 npm 包时，个别该包的地位并不在我的项目目录中，为了不便开发，能够应用`npm link` 将该包链接到我的项目中，不便开发调试。（注：尽量不要间接在我的项目的 node_moudles 中创立本地包进行开发，如果 package.json 中没有写依赖，很容易在更新其余包的时候造成本地包失落，血泪的教训……????)	`npm link` 1, 在本地包 test 包关上终端执行 `npm link` 将包链接到全局 2，在我的项目根目录下执行`npm link test` 将包链接到我的项目中

npm init 会创立 package.json 文件官网文档

name

包的名字（必填字段），
· 名称必须少于或等于 214 个字符，
· 不能以 ’.’ 或者 ’_’ 结尾,
· 名称中不能蕴含大写字母，
· 肯定要简短并高度概括，
· 不能和 npm 其余包重名，否则公布不胜利
· 名称能够带前缀，eg. @babel/cli 装置之后的目录如下：

version

版本（必填字段）
版本号由三个数组用. 隔开别离是 [大版本，主要版本，修复版本]
大版本 ：版本有重大降级，不向下兼容，降级需谨慎。eg. react@15.x 和 react@16.x、webpack@3.x 和 webpack@4.x
主要版本 ：版本有新性能，并向下兼容，能够随时更新。
修复版本：版本次要修复了 bug，能够随时更新。

"latest": 最新版,npm i 时会装置最新的大版本，相对不要用这个，十分不平安
"beta|test|alpha": 默认装置最新的 tag 版，对于公布 tag 的标准能够参考 semver
"1.0.0": 精准匹配版本号
"^1.0.0": 匹配 2，3 级版本。eg. 能够匹配大于等于 1.0.0 小于 2.0.0 的版本
"~1.0.0": 匹配 3 级版本。eg. 能够匹配大于等于 1.0.0 小于 1.1.0 版本, 但匹配不到 1.1.0 版本
"~1.2.3-beta.1"：匹配大于等于 1.2.3-beta.1 小于 1.3.0 的版本，然而须要留神的是如果是 beta 版，只能匹配大于等于 1.2.3-beta.1 小于 1.2.4-beta.1 的版本。也就是说 beta 版本前缀不能大于 1.2.3，正式版能够大于1.2.3 小于1.3.0
">1.0.0": 匹配大于该版本的。
">=1.0.0": 匹配大于等于该版本的。
"<1.0.0": 匹配小于该版本的。
"<=1.0.0": 匹配小于等于该版本的。
"=1.0.0": 匹配等于该版本的，和不加 "=" 的状况一样。
">=1.0.0 <2.0.0": 匹配大于等于 1.0.0，小于2.0.0 的。
"1.3.4 || >=1.0.0 <2.0.0": 匹配 1.3.4 或大于等于1.0.0，小于 2.0.0 的。
"1.0.0-beta.1"：tag 版，如果不小心将 tab 版本执行了 npm publish 公布成了正式版，这时只有执行 npm dist-tag add 1.0.0-beta.1 latest 即可把该 tag 版转为正式版
"1.2.3 - 2.3.4": 匹配 1.2.3 到2.3.4之间的版本，如果只提供了一级或二级版本则匹配一级或二级最大版本。
eg. 1.2.3 - 2 –> 匹配大于等于 1.2.3 小于 3.0.0 的版本。
"1.x": 匹配大于等于 1.0.0 小于 2.0.0 的版本, 等同于"^"
"1.2.x"：匹配大于等于 1.2.0 小于 1.3.0 的版本, 等同于"~"
"*"：匹配任何版本
""：匹配任何版本, 等同于*
"1"：匹配大于等于 1.0.0 的版本，等同于1.x
"1.2"：匹配大于等于 1.2.0 的版本，等于1.2.x

description|keywords

包的形容 / 关键词, 能够通过 npm search 来搜寻

main

包的入口文件，默认为 index.js，
browser 环境和 node 环境均可应用

author

包的作者

scripts

用来定义一些脚本命令命令如：start,dev,build 等

repository

代码寄存的中央 type 能够是 svn 或 git
url 为拜访门路

"repository": { 
    "type" : "git", 
    "url" : "https://github.com/npm/cli.git" 
}

maintainers

包的所有者列表，通过 npm owner add 增加的都会呈现在此列表

homepage

我的项目主页地址

bugs

我的项目问题的提交地址

license

包的证书，指定了使用者应用的的权限

files

一个文件类型的数组，用来示意在以后包作为依赖包时装置并显示的目录，语法相似于.npmignore 文件，示意含意刚好相同，.npmignore 里的代表装置时要疏忽的；写入 flies 的代表装置时不疏忽的

browser

指定该包在客户端应用

bin

指定 script 字段中的命令的执行文件
eg. {"bin" : { "myapp" : "./cli.js"} } 这样在 script 能够简写成: script:{"start": "myapp start"}
注：确保援用的文件（cli.js）头部引入#!/usr/bin/env node

man

man 是 manual 的缩写，man 命令用来查看帮忙文档的，如 Linux 中的命令帮忙、配置文件帮忙、编程帮忙等信息，咱们在 package.json 中配置之后，那包装置之后能够通过 man <Pacakge Name> 来查找到包中的帮忙文档。
附上官网例子：

{ 
    "name" : "foo" ,
    "version" : "1.2.3" ,
    "description" : "A packaged foo fooer for fooing foos" ,
    "main" : "foo.js" ,
    "man" : "./man/doc.1" 
}

以上代码执行 man foo 能够查找到./man/doc.1 文件内容

如果文件名不是以包名开始的，则 man 命令会主动创立前缀，如下：

{ 
    "name" : "foo" , 
    "version" : "1.2.3" , 
    "description" : "A packaged foo fooer for fooing foos" ,
    "main" : "foo.js" , 
    "man" : \["./man/foo.1", "./man/bar.1" \] 
}

以上代码会创立 man foo 和 man foo-bar命令来查问文件

文件须要以数字结尾，或者当文件压缩时以 .gz 结尾，数字代表的是文件装置在 man 命令的哪局部。

directories

目前这个配置没什么用

config

能够用 config 在 package.json 中设置一些不会变动的配置参数，详情请查看 npm-config, 附上官网的例子：

{"name" : "foo" , "config" : { "port" : "8080"} }

而 server.js 是这样的：

http.createServer(...).listen(process.env.npm_package_config_port)

那么用户能够通过以下形式更改行为：

npm config set foo:port 80

dependencies

以后包的依赖包，生产环境须要打包在我的项目中时应用（eg. react、vue、antd 等须要打包后在生产环境应用的包）。能够是具体的包，也能够是 git 地址或压缩包。罕用的一些例如：

"dependencies": {
    "prop-types": "^15.7.2",
    "react": "~16.8.6",
    "react-dom": "latest",
    "easy-danmaku": "/Users/jamie/work/fe/cnpm/danmaku",
    "xxx": "git+https://github.com/xxx/xxxx.git"~~~~
},

在咱们执行 npm i 时可能会遇到这样的景象，

A 包中的依赖 B 包为什么装置后在 node_modules 里 A 包，B 包都同级了，B 包并没有装置在 A 包的 node_modules 里？
为什么 A 包中依赖 B 包，c 包也依赖 B 包，为什么装置后有时候 C 包和 A 包、B 包同级，有时候又别离装置到各自的 node_modules 里了？

在解释这个问题之前，能够先查看一下本人的 npm 版本号，npm -v 如果 npm 版本号大于 3.x, 这个版本的 npm 采纳了包治理所以会呈现下面说的景象。如果版本为 npm2.x，属于嵌套模式，所有包的依赖包都会别离打包在本人的 node_modules 中，造成嵌套过深的问题。这里咱们次要说 npm3.x 的包治理，如果 A 包，B 包依赖的 C 包版本雷同，则装置后会平铺在 node_modules 里，如果版本不同则会别离打包到各自的 node_modules 里。

注：在应用过程中发现，依赖包版本号为 beta 时，不会扁平化装置，如果须要扁平化装置须要写版本号或 latest, 这就造成了另一个版本抵触的问题，这时应用 peerDependency 更适合，下文会具体阐明

devDependencies

开发环境须要应用的工具类依赖包（eg. babel、webpack、eslint、typescript 等须要在开发中用到的打包，编译，检测等工具包）。

peerDependencies

提醒装置时须要将 peerDependencies 中的依赖作为我的项目依赖装置。在 npm3.x 后，如果包的依赖为 peerDependencies，则会在装置过程中提醒须要手动装置 peerDependencies 的依赖。作用是避免我的项目曾经依赖了 C 包，装置的 A 包中也依赖了 C 包。两处的 C 包因版本不统一而导致的问题。

optionalDependencies

可选依赖包，用来放一些不阻断我的项目失常运行的插件包，即便这些包装置失败也不会阻塞 npm 的继续执行。须要留神的是 optionalDependencies 里的包会笼罩 dependencies 里的

bundledDependencies

捆绑组件包，打包后会将依赖包一并打包进去，装置时只需装置一个包即可，须要留神的是 bundledDependencies 中的依赖包须要先在 dependencies 或 devDependencies 中定义，在执行 npm pack 的时候才会打包进去

publishConfig

发包时设置该包公布的仓库地址，个别公司有外部公有仓库时，这里设置为该仓库地址。

"publishConfig": {"registry": "http://xxx/xxxx/repository/cnpm/"}

咱们公司也有外部仓库然而发包是并不需要设置 publishConfig，而是所有包都是在一个作用域下，例如：@babel/core的模式

publishConfig决定发包到哪，.npmrc决定从哪装置。对于 .npmrc 的具体解释与用法请看下文。

engines

指定包的运行引擎。
eg.

{"engines" : { "node" : ">=0.10.3 <0.12"} }
// or
{"engines" : { "npm" : "~1.0.20"} }

指定该包只能在 node 版本大于等于 0.10.3 小于 0.12 或 npm 版本大于等于 1.0.20 小于 1.1.0 的版本上运行）

os

指定包运行的操作系统。
eg.

{"os" : [ "darwin", "linux"]}

或者指定不能在某些操作系统运行

{"os" : [ "!win32"]}

cpu

指定包运行的 cpu
eg.

{"cpu" : [ "x64", "ia32"]}

或则指定不能在某些 cpu 运行，相似 os

private

如果设置为 true，npm publish 时会无奈公布，这是为了避免将不能公布的包误公布，没什么用途

package.json 中还能够增加一些非官方的工具类配置。
eg. 当咱们查看 antd 的 package.json 时会发现有一些并不是官网文档里的，有一篇文章总结的很不错，点击这里看非官方配置

npm 源

说到 npm 源就须要介绍一下.npmrc 文件，文件次要是用来设置 npm 源的，npm 默认都是指向 https://registry.npmjs.org/ 然而为了晋升装置速度，须要设置源为https://registry.npm.taobao.org/ 然而当咱们依赖包里又有 npm 包，又有公司公有仓库包时，须要将某些包的 npm 源指向公司公有仓库地址。拿咱们公司举例，假如咱们的 npm 包作用域为@test 我须要将@test 下的包的源指到公司仓库地址, 这样我执行 npm i 时能够同时装置 npm 上和公司外部的包

npm config set @test:registry http://registry.xxxx.xxx.com

npm config set 其实是在 .npmrc 中设置了源，如果想间接关上文件设置，能够执行 npm config ls -l 找到 .npmrc 文件的地位进行

或者在终端间接执行 npm config edit 进行编辑
举荐一个好用的随时切换 npm 源的工具nrm

package-lock.json

咱们常常会发现在执行 npm i 时会默认在根目录生成 package-lock.json 文件，关上查看会发现都是咱们一些依赖包的相干信息

package-lock.json 是用来锁定版本的，也就是说每次装置都会默认装置 package-lock.json 中的版本，如果多人开发，能够保障版本统一。
注：如果手动批改了 package.json 中的版本号，间接执行 npm i 后发现装置的并不是 package.json 中的版本号，这时须要删除 package-lock.json 文件再装置，或间接装置某个特定包

npm 官网文档：
https://docs.npmjs.com/cli-documentation/
https://docs.npmjs.com/files/package.json.html

正文完