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: 删除文件
...
来源: http://www.bubuko.com/infodetail-3190197.html