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