react学习之基础环境

环境搭建

安装nodejs

node_modules

  • 搜索路径
  1. Node将试图去当前目录的node_modules文件夹里搜索。如果当前目录的node_modules里没有找到,Node会从父目录的node_modules里搜索,这样递归下去直到根目录。(框架组件我们安装的只有源码,组件库还是依赖于我们本地)
  • 好处
  1. 使用package.json安装好之后,node_modules文件夹中没有版本信息,从而package.json可以删掉了。
  2. 移动/复制/打包项目比较简单,对于开发、部署都有好处
  3. 随意改代码。安装在node_modules里面的东西,你可以随便改,无需担心对其它项目的影响。在Java中使用maven管理项目时,如果想要定制某个库,就需要更改这个库的源代码,这时就需要把这个库的源代码复制到项目中,跟node_modules是一个道理。npm的设计者大概认为:前端都是经常修改库的源代码的。
  • 坏处
  1. 每次都需要安装依赖,费流量,网速慢时很费时间
  2. 浪费磁盘空间,每个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
posted @ 2020-07-02 14:29  福小松  阅读(168)  评论(0编辑  收藏  举报