1.在本地项目中基于NPM/YARN安装第三方模块
第一步:在本地项目中创建一个“package.json”的文件
作用:把当前项目所有依赖的第三方模块信息(包含:模块名称以及版本号等信息)都记录下来;可以在这里配置一些可执行的命令脚本等;基于YARN会默认生成一个“配置清单”,只是信息没有手动创建的全面
npm init -y 或者 yarn init -y
创建配置清单的时候,项目目录中不应该出现中文和特殊符号,这样有可能识别不了
第二步:安装
开发依赖:只有在项目开发阶段依赖的第三方模块
生产依赖:项目部署实施的时候,也需要依赖的第三方模块[npm]
npm install xxx --save 保存到配置清单的生产依赖中
--save-dev 保存到开发依赖中[yarn]
yarn add xxx 默认就是保存到生产依赖中
--dev / -D 保存到开发依赖中第三步:部署的时候“跑环境”
不要自己一个个的安装,只需要执行 npm install 或者 yarn install 即可,npm会自己先检测目录中是否有package.json文件,如果有的话,会按照文件中的配置清单依次安装
=>开发一个项目,我们生成一个配置清单“package.json”,当我们安装第三方模块使用的时候,把安装的模块信息记录到配置清单中,这样以后不管是团队协作开发还是项目部署上线,我们都没有必要把node_modules发文件发送给别人,只需要把配置清单传递给其它人即可,其他人拿到配置清单后,按照清单中依赖项及版本号,重新安装即可(重新安装:“跑环境”)
package.json
{
"name": "0609DAY1", //=>模块名称
"version": "1.0.0", //=>版本号
"description": "", //=>模块的描述
"main": "index.js", //=>当前模块的主入口文件
"dependencies": { //=>生产依赖
"zepto": "^1.2.0"
},
"devDependencies": { //=>开发依赖
},
"scripts": { //=>可执行脚本
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
2.安装在本地和全局的区别
[安装在全局的特点]
1.所有的项目都可以使用这个模块
->容易导致版本冲突
->安装在全局的模块,不能基于CommonJS模块规范调取使用(也就是不能在JS中通过REQUIRE调取使用)[安装在本地的特点]
1.只能当前项目使用这个模块
->不能直接的使用命令操作(安装在全局可以使用命令)
为啥安装在全局下可以使用命令?
npm root / -g 查看本地项目或者全局环境下,NPM的安装目录
安装在全局目录下的模块,但部分都会生成一个xxx.cmd的文件,只要有这个文件,那么xxx就是一个可执行的命令(例如:yarn.cmd => yarn就是命令)
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\yarn\bin\yarn.js" %*
) ELSE (
@SETLOCAL
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\yarn\bin\yarn.js" %*
)
能否即安装在本地,也可以使用命令操作?
可以,但是需要配置package.json中的scripts
1.把模块安装在本地,如果是支持命令操作的(会在node_modules的bin中生成xxx.cmd的命令文件,只不过这个文件无法在全局下执行 =>不能直接用命令)
2.在package.json的scripts中配置需要执行的命令脚本
"scripts": {
"zxt": "lessc -v" 属性名自己设置即可,属性值是需要执行的命令脚本,根据需要自己编写(可以配置很多命令的)
}3.npm run zxt / yarn zxt 这样的操作就是把配置的脚本执行
->首先到配置清单的scripts中查找
->找到把后面对应的属性值(执行脚本)执行
->执行脚本的时候,会到本地node_modules中的bin文件加查找,没有的话,在向NPM安装的全局目录下查找
3.NODE入门
NODE本身是基于CommonJS模块规范设计的,所以模块是NODE的组成
- 内置模块:NODE天生提供给JS调取使用的
- 第三方模块:别人写好的,我们可以基于NPM安装使用
- 自定义模块:自己创建一些模块
CommonJS模块化设计的思想(AMD/CMD/ES6 MODULE都是模块设计思想)
1.CommonJS规定,每一个JS都是一个单独的模块(模块是私有的:里面涉及的值和变量以及函数等都是私有的,和其它JS文件中的内容是不冲突的)
2.CommonJS中可以允许模块中的方法互相的调用
B模块中想要调取A模块中的方法
=>A导出
=>B导入
[导出]
CommonJS给每一个模块(每个JS)中都设置了内置的变量/属性/方法
module:代表当前这个模块[object]
module.exports:模块的这个“属性”是用来导出当前模块的属性和方法的 [object]
exports:是内置的一个“变量”,也是用来导出当前模块属性方法的,虽然和module.exports不就是一个东西,但是对应的值是同一个(module.exports=exports 值都是对象)
[导入]
require:CommonJS提供的内置变量,用来导入模块的(其实导入的就是module.exports暴露出来的东西);导入的值也是[object]类型的;
CommonJS特点:
1. 所有代码都运行在模块作用域,不会污染全局作用域(每一个模块都是私有的,包括里面所有的东西也都是私有的,不会和其它模块产生干扰)
2. 模块可以多次加载,但是只会在第一次加载时运行一次,然后运行结果就被缓存了,以后再加载,就直接读取缓存结果。要想让模块再次运行,必须清除缓存。(为了保证性能,减少模块代码重复执行的次数)
3. 模块加载的顺序,按照其在代码中出现的顺序。CommonJS规范加载模块是同步的,也就是说,只有加载完成,才能执行后面的操作。
案例:A/B/C三个模块
A中有一个sum方法:实现任意数求和
B中有一个avg方法:实现任意数求平均(先求和再求平均:B中用到A)
C中调取B中的avg,实现 12,23,34,45,56,67,78,89 求平均数
require导入规则
require('./xxx') 或者 ../xxx 再或者 /xxx,这种自己制定路径的模式,都是为了导入自定义的模块,换句话说,想要导入自定义的模块,必须加路径
require('xxx') 首先到当前项目的node_modules中查找是否存在这个模块,不存在找node提供的内置模块(导入第三方或者内置的)
__dirname:模块中这个内置变量是当前模块所在的绝对路径(具体到盘符:物理路径 例如:E:\201802LESSON\WEEK9\0609DAY1; 相对路径:WEEK9\0609DAY1 相对于根目录的路径;)
__filename:相对于__dirname来讲,多了模块名称,例如:E:\201802LESSON\WEEK9\0609DAY1\C.js
4.NODE中的内置模块
http://nodejs.cn/api/
【fs内置模块:实现I/O操作】
let fs = require('fs');
1. fs.mkdir / fs.mkdirSync:创建文件夹,有Sync的是同步创建,反之没有是异步,想要实现无阻塞的I/O操作,我们一般都是用异步操作完成要处理的事情
2. fs.readdir / fs.readdirSync:读取文件目录中的内容
3. fs.rmdir :删除文件夹
4. fs.readFile:读取文件中的内容
5. fs.writeFile:向文件中写入内容(覆盖写入:写入的新内容会替换原有的内容)
6. fs.appendFile:追加写入新内容,原有的内容还在
7. fs.copyFile:拷贝文件到新的位置
8. fs.unlink:删除文件
...