环境搭建
安装nodejs
node_modules
- 搜索路径
- Node将试图去当前目录的node_modules文件夹里搜索。如果当前目录的node_modules里没有找到，Node会从父目录的node_modules里搜索，这样递归下去直到根目录。（框架组件我们安装的只有源码，组件库还是依赖于我们本地）
- 好处
- 使用package.json安装好之后，node_modules文件夹中没有版本信息，从而package.json可以删掉了。
- 移动/复制/打包项目比较简单，对于开发、部署都有好处
- 随意改代码。安装在node_modules里面的东西，你可以随便改，无需担心对其它项目的影响。在Java中使用maven管理项目时，如果想要定制某个库，就需要更改这个库的源代码，这时就需要把这个库的源代码复制到项目中，跟node_modules是一个道理。npm的设计者大概认为：前端都是经常修改库的源代码的。
- 坏处
- 每次都需要安装依赖，费流量，网速慢时很费时间
- 浪费磁盘空间，每个node_modules中包含的工具很多，动辄20M
npm 中的依赖包
这里只说我们常用的两个依赖包 dependenices 和 devDependenices,其它的一些依赖包只有作为包的发布者才会用到，需要的小伙伴自行查看文档。
dependenices
-
通过命令npm install/i packageName -S/--save把包装在此依赖项里。如果没有指定版本，直接写一个包的名字，则安装当前npm仓库中这个包的最新版本。如果要指定版本的，可以把版本号写在包名后面，比如npm i vue@3.0.1 -S。
-
从npm 5.x开始，可以不用手动添加-S/--save指令，直接执行npm i packageName把依赖包添加到dependencies中去。
-
不仅开发环境能使用，生产环境也能使用
devDependenices
- 只会在开发环境下依赖的模块，生产环境不会被打入包内
- 有一些包有可能你只是在开发环境中用到，例如你用于检测代码规范的 eslint ,用于进行测试的 jest ，用户使用你的包时即使不安装这些依赖也可以正常运行，反而安装他们会耗费更多的时间和资源，所以你可以把这些依赖添加到 devDependencies 中，这些依赖照样会在你本地进行 npm install 时被安装和管理，但是不会被安装到生产环境：
版本管理
分为三个版本
- 主版本号（A）：当你做了不兼容的 API 修改，0表示处于开发阶段；
- 次版本号（B）：当你做了向下兼容的功能性新增;
- 修订号（C）：当你做了向下兼容的问题修正。
~允许小版本迭代
- 如果有缺省值，缺省部分任意迭代；
- 如果没有缺省值，只允许补丁即修订号（Patch）的迭代
eg.:
- ~1.2.3：>=1.2.3 <1.3.0
- ~1.2：>=1.2.0 < 1.3.0（相当于1.2.x）
- ~1：>=1.0.0 <2.0.0（相当于1.x）
- ~0.2.3：>=0.2.3 <0.3.0
- ~0.2：>=0.2.0 <0.3.0（相当于0.2.x）
- ~0：>=0.0.0 <1.0.0（相当于0.x）
^允许大版本迭代
- 允许从左到右的第一段不为0那一版本位+1迭代（左闭右开）；
如果有缺省值，且缺省值之前没有不为0的版本位，则允许缺省值的前一位版本+1迭代
eg.: - ^1.2.3：>=1.2.3 <2.0.0
- ^0.2.3：>=0.2.3 <0.3.0
- ^0.0.3：>=0.0.3 <0.0.4
- ^1.2.x：>=1.2.0 <2.0.0
- ^0.0.x：>=0.0.0 <0.1.0
- ^0.0：>=0.0.0 <0.1.0
- ^1.x：>=1.0.0 <2.0.0
- ^0.x：>=0.0.0 <1.0.0
每个npm包都有一个package.json，如果要发布包的话，package.json里面的version字段就是决定发包的版本号了。
version字段是这样一个结构： ‘0.0.1’，是有三位的版本号。分别是对应的version里面的：major, minor, patch。
也就是说当发布大版本的时候会升级为 1.0.0，小版本是0.1.0，一些小修复是0.0.2。
锁定（控制）版本
package-lock.json或是yarn.lock。
在npm的版本>=5.1的时候，package-lock.json文件是自动打开的，意味着会自动生成，
package-lock.json（官方文档）可以理解为/node_modules文件夹内容的json映射，并能够感知npm的安装/升级/卸载的操作。可以保证在不同的环境下安装的包版本保持一致。听上去很不错哈，实际使用中，大部分它的表现确实不错，可是如上述问题：我手动修改了package.json文件内依赖的版本，package-lock.json就没那么聪明（至少目前是，未来会不会变聪明就不可知了），且不会变化。
如果你真的想保证你的包版本在各个环境都是一样的话，请修改下package.json中的依赖，去掉默认前面的^，当然这样的话，你就没法自动享受依赖包小版本的修复了，问题来了，在什么情况下选择哪一种呢？
在依赖包严格按照版本规范来开发的，你可以使用^来享受包的最新功能和修复。这也是推荐的。
在你不可知或已知依赖包不是那么规范的情况下，或许它在一个小版本（patch）做出不兼容更改（不兼容更改在beta等先行版本中一定[墨菲定律]会发生），那么这个时候，你应该把这个依赖包的版本在package.json上锁住版本，而不应该把它交给package-lock.json来处理
记住一点，绝对不要在生成环境下使用beta等先行版本依赖包，因为如果那是你的私有项目，它会在未来的某一刻坑害了你，如果这是你的共有项目，那么，它一定会在未来的某一刻对你的所有用户做出致命的坑害行为！（beta包就是不负责任的流氓包，玩家爽就好 ）
- 最后：rm -rf node_modules/ && npm install大法在你使用package-lock的情况下，请更换为：rm -rf node_modules && rm -rf package-lock.json && npm install。
scripts
什么是 npm script 脚本?
在生成的 package.json 文件中，有一个 scripts 对象，在这个对象中，npm 允许使用 scripts 字段定义脚本命令。
"scripts": {
"start": "cross-env electronMode=dev node --trace-warnings -r babel-register ./node_modules/webpack-dev-server/bin/webpack-dev-server --mode development --config webpack.config.dev.js",
"doc": "styleguidist server",
"doc-build": "styleguidist build",
"test": "jest",
"release": "cross-env operation=separateCSS node --trace-warnings -r babel-register ./node_modules/webpack/bin/webpack --mode production --config webpack.config.prod.js --colors --progress",
"deploy": "npm run release && deploy-client"
},
原理
-
我们每次在运行 scripts 中的一个属性时候(npm run),**实际系统都会自动新建一个shell(一般是Bash)，在这个shell里面执行指定的脚本命令。因此 凡是能在 shell 中允许的脚本，都可以写在npm scripts中。
-
scripts 对象中每一个属性，对应一段脚本。比如，test 命令对应的脚本是 node test.js。命令行下使用 npm run 命令，就可以执行这段脚本。
-
c
常用规则
- npm start、npm stop、npm test
- 正常情况下，npm 脚本是用户自己定义。不常用的命令需要run
"start": "node server.js"
"release": "cross-env operation=separateCSS node --trace-warnings -r babel-register ./node_modules/webpack/bin/webpack --mode production --config webpack.config.prod.js --colors --progress",
- npm start
- npm run release
执行顺序
npm 脚本执行多任务分为两种情况
- 并行任务(同时的平行执行)，使用&符号
$ npm run script1.js & npm run script2.js
- 串行任务(前一个任务成功，才执行下一个任务)，使用 && 符号
$ npm run script1.js && npm run script2.js