Node基础-CommonJS模块化规范

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：删除文件

...

```