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

前言

本文总结了工作中罕用到的以及一些不罕用容易疏忽的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`将包链接到我的项目中

pacakge.json

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的版本上运行）

指定包运行的操作系统。
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源

说到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文件再装置，或间接装置某个特定包

Reference

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

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

前言

根本命令速览

pacakge.json

npm 其余知识点

npm源

package-lock.json

Reference

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

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

前言

根本命令速览

pacakge.json

npm 其余知识点

npm源

package-lock.json

Reference

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复