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：删除文件
...原文地址：https://www.cnblogs.com/jiajialove/p/11493257.html
时间： 2024-10-12 01:29:31