在cachedInput、output、watch三大文件系统中,output非常简单,没有必要讲,其余两个模块依赖于input模块,而input主要是引用了graceful-fs的部分API,所以这节来讲讲graceful-fs。

  上一节整理的源码如下:

var fs = require('fs')

// ...工具方法

module.exports = patch(require('./fs.js'))
if (process.env.TEST_GRACEFUL_FS_GLOBAL_PATCH) {
module.exports = patch(fs)
} module.exports.close = fs.close = (function(fs$close) { /*...*/ })(fs.close) module.exports.closeSync = fs.closeSync = (function(fs$closeSync) { /*...*/ })(fs.closeSync) function patch(fs) {
// fs方法二次封装
return fs
}

  内容包含:

1、工具方法

2、patch引入的fs模块并输出

3、添加close/closeSync方法

util.debuglog

  首先看工具方法,代码如下:

var util = require('util');// 检测此方法是否存在并返回一个debug方法
if (util.debuglog)
debug = util.debuglog('gfs4');
// 测试进程参数NODE_DEBUG是否包含'gfs4'
else if (/\bgfs4\b/i.test(process.env.NODE_DEBUG || '')) {
// 自定义一个debug函数
debug = (...args) => {
var m = util.format.apply(util, args);
m = 'GFS4: ' + m.split(/\n/).join('\nGFS4: ');
console.error(m);
}
} if (/\bgfs4\b/i.test(process.env.NODE_DEBUG || '')) {
// 监听退出事件
process.on('exit', function() {
// 批量输出日志内容
debug(queue);
// 使用==测试参数是否相等 不等抛出error
require('assert').equal(queue.length, 0);
})
}

  这里会尝试调用util.debuglog来生成一个错误日志函数,每一次调用该函数会打印一条错误日志。

  在没有util.debuglog的情况下后自定义一个debug函数,测试代码如图:

const util = require('util');
debug = (...args) => {
var m = util.format.apply(util, args);
m = 'GFS4: ' + m.split(/\n/).join('\nGFS4: ');
console.error(m);
}
debug(`log1
log2
log3`);

  执行后输出如图:

  这里可以顺便看一下nodejs中debuglog的源码,整理如下:

var debugs = {};
// 收集所有DEBUG的环境名
var debugEnviron; function debuglog(set) {
if (debugEnviron === undefined) {
// 从NODE_DEBUG环境变量中收集所有的日志输出参数
// 这里全部转为大写
// 这就说明为什么debuglog传的是gfs4 输出的是GFS4
debugEnviron = new Set(
(process.env.NODE_DEBUG || '').split(',').map((s) => s.toUpperCase()));
}
set = set.toUpperCase();
// 没有该debuglog函数就创建一个
if (!debugs[set]) {
// 只对指定的参数进行输出
if (debugEnviron.has(set)) {
var pid = process.pid;
debugs[set] = function() {
// 格式化参数信息
var msg = exports.format.apply(exports, arguments);
// 依次输出:参数名 进程号 信息
console.error('%s %d: %s', set, pid, msg);
};
} else {
debugs[set] = function() {};
}
}
return debugs[set];
}

  可以看到,源码内部也是用console.error来进行错误日志输出,输出的格式比模拟方法多了一个进程号,基本上没啥区别。

  官网的实例我测不出来,先搁着,下面讲模块输出。

 模块输出'./fs.js'

  模块的输出有两个方式,取决的系统环境信息 TEST_GRACEFUL_FS_GLOBAL_PATCH ,这个参数可以设置,默认是undefined。

  若该值未设置,会调用本地的fs来进行patch,这个本地fs源码如下:

'use strict'

var fs = require('fs')

module.exports = clone(fs)
// 拷贝对象
function clone(obj) {
if (obj === null || typeof obj !== 'object')
return obj
if (obj instanceof Object)
var copy = { __proto__: obj.__proto__ }
else
var copy = Object.create(null)
Object.getOwnPropertyNames(obj).forEach(function(key) {
Object.defineProperty(copy, key, Object.getOwnPropertyDescriptor(obj, key))
})
return copy
}

  会深拷贝基本类型,但是对于复杂类型也只是浅拷贝,测试代码如下:

const a = {
'string': 1,
'arr': [1],
}
const b = clone(a);
b.arr[0] = 2;
b.string = 2;
console.log(a); // {string:1,arr:[2]}
const c = a;
c.arr[0] = 3;
c.string = 3;
console.log(a); // {string:3,arr:[3]}

  总之,基本上相当于返回一个fs模块。

  无论如何,graceful-js都是输出patch后的fs模块,先不看同步/异步close,主要看patch方法是如何对原生API进行封装的,整理后源码如下:

function patch(fs) {
// Everything that references the open() function needs to be in here
// 跨平台兼容处理
polyfills(fs)
fs.gracefulify = patch;
// 遗留名字
fs.FileReadStream = ReadStream; // Legacy name.
fs.FileWriteStream = WriteStream; // Legacy name.
// 创建流
fs.createReadStream = createReadStream
fs.createWriteStream = createWriteStream var fs$readFile = fs.readFile;
fs.readFile = readFile;
// 读取文件
function readFile(path, options, cb) { /*...*/ } var fs$writeFile = fs.writeFile;
fs.writeFile = writeFile;
// 写文件
function writeFile(path, data, options, cb) { /*...*/ } var fs$appendFile = fs.appendFile;
if (fs$appendFile)
fs.appendFile = appendFile;
// 文件添加内容
function appendFile(path, data, options, cb) { /*...*/ } var fs$readdir = fs.readdir;
fs.readdir = readdir;
// 读取目录
function readdir(path, options, cb) { /*...*/ } function go$readdir(args) { /*...*/ } if (process.version.substr(0, 4) === 'v0.8') { /*...*/ }
// 流处理
// 可读的流
var fs$ReadStream = fs.ReadStream;
ReadStream.prototype = Object.create(fs$ReadStream.prototype);
ReadStream.prototype.open = ReadStream$open;
// 可写的流
var fs$WriteStream = fs.WriteStream;
WriteStream.prototype = Object.create(fs$WriteStream.prototype);
WriteStream.prototype.open = WriteStream$open; fs.ReadStream = ReadStream
fs.WriteStream = WriteStream function ReadStream(path, options) { /*...*/ } function ReadStream$open() { /*...*/ } function WriteStream(path, options) { /*...*/ } function WriteStream$open() { /*...*/ } function createReadStream(path, options) { /*...*/ } function createWriteStream(path, options) { /*...*/ }
var fs$open = fs.open;
fs.open = open;
// 以某种形式打开文件
function open(path, flags, mode, cb) { /*...*/ }
return fs
}

  基本上文件操作API均有涉及,兼容处理这里不讨论。

  tips:以fs$***开头的变量均为原生API,例如fs$readFile代表原生的fs.readFile

  tips:源码有些写法真的僵硬,进行了一些优化增加可读性

  功能主要分为下列几块:

1、读取文件全部内容

2、写入数据到文件

3、向文件添加数据

4、读取目录

5、打开文件

6、流相关

  依次进行讲解。

文件读取:readFile

  源码如下:

function readFile(path, options, cb) {
// options参数可选
// 若第二参数为函数 代表省略了options参数
if (typeof options === 'function')
cb = options, options = null;
// 调用原生的fs.readFile
return go$readFile(path, options, cb) function go$readFile(path, options, cb) {
return fs$readFile(path, options, function(err) {
// 如果出错记录下来
if (err && (err.code === 'EMFILE' || err.code === 'ENFILE')) {
// 分别为fs模块类型 参数
enqueue([go$readFile, [path, options, cb]])
} else {
if (typeof cb === 'function')
cb.apply(this, arguments)
retry()
}
})
}
} // 记录错误
function enqueue(elem) {
debug('ENQUEUE', elem[0].name, elem[1])
queue.push(elem)
} // 重试之前产生报错的行为
function retry() {
var elem = queue.shift()
if (elem) {
debug('RETRY', elem[0].name, elem[1])
elem[0].apply(null, elem[1])
}
}

  总结一下graceful-fs的优雅行为:

1、底层仍然调用的是nodejs原生API

2、当某个fs行为出错,该fs操作类型与参数会被记录下来

3、当某个fs行为成功执行,会尝试将最早出错的行为取出并再次执行,出错会再次被记录

  其余方法诸如writeFile、appendFile、readdir均与此类似,而流的抽象接口也并没有做什么额外操作,只是对读写操作中的open进行了上述加工,这里就不进行讲解了。

close/closeSync

  这两个方法用了大量注释,我还以为有啥特殊功能,代码如下:

// Always patch fs.close/closeSync, because we want to
// retry() whenever a close happens *anywhere* in the program.
// This is essential when multiple graceful-fs instances are
// in play at the same time.
module.exports.close =
fs.close = (function(fs$close) {
return function(fd, cb) {
return fs$close.call(fs, fd, function(err) {
// 关闭之前进行重试一次
if (!err)
retry() if (typeof cb === 'function')
cb.apply(this, arguments)
})
}
})(fs.close) module.exports.closeSync =
fs.closeSync = (function(fs$closeSync) {
return function(fd) {
// Note that graceful-fs also retries when fs.closeSync() fails.
// Looks like a bug to me, although it's probably a harmless one.
var rval = fs$closeSync.apply(fs, arguments)
retry()
return rval
}
})(fs.closeSync)

  其实这里的注释还是蛮有味道的,尤其是下面的closeSync,第一次见源码注释带有作者第一人称的特殊解释(me)

  至此,grace-ful模块解析完成,其实内容并没有多复杂。

.10-浅析webpack源码之graceful-fs模块的更多相关文章

  1. .17-浅析webpack源码之compile流程-入口函数run

    本节流程如图: 现在正式进入打包流程,起步方法为run: Compiler.prototype.run = (callback) => { const startTime = Date.now( ...

  2. .3-浅析webpack源码之预编译总览

    写在前面: 本来一开始想沿用之前vue源码的标题:webpack源码之***,但是这个工具比较巨大,所以为防止有人觉得我装逼跑来喷我(或者随时鸽),加上浅析二字,以示怂. 既然是浅析,那么案例就不必太 ...

  3. 浅析libuv源码-node事件轮询解析(3)

    好像博客有观众,那每一篇都画个图吧! 本节简图如下. 上一篇其实啥也没讲,不过node本身就是这么复杂,走流程就要走全套.就像曾经看webpack源码,读了300行代码最后就为了取package.js ...

  4. 从Webpack源码探究打包流程,萌新也能看懂~

    简介 上一篇讲述了如何理解tapable这个钩子机制,因为这个是webpack程序的灵魂.虽然钩子机制很灵活,而然却变成了我们读懂webpack道路上的阻碍.每当webpack运行起来的时候,我的心态 ...

  5. 10个带源码的充满活力的Web设计教程

    10个带源码的充满活力的Web设计教程 2013-08-02 16:47 佚名 OSCHINA编译 我要评论(0) 字号:T | T Web设计师必须了解各种各样的Web设计风格,这才能让他或者她在设 ...

  6. .30-浅析webpack源码之doResolve事件流(1)

    这里所有的插件都对应着一个小功能,画个图整理下目前流程: 上节是从ParsePlugin中出来,对'./input.js'入口文件的路径做了处理,返回如下: ParsePlugin.prototype ...

  7. .34-浅析webpack源码之事件流make(3)

    新年好呀~过个年光打游戏,function都写不顺溜了. 上一节的代码到这里了: // NormalModuleFactory的resolver事件流 this.plugin("resolv ...

  8. .30-浅析webpack源码之doResolve事件流(2)

    这里所有的插件都对应着一个小功能,画个图整理下目前流程: 上节是从ParsePlugin中出来,对'./input.js'入口文件的路径做了处理,返回如下: ParsePlugin.prototype ...

  9. webpack源码-依赖收集

    webpack源码-依赖收集 version:3.12.0 程序主要流程: 触发make钩子 Compilation.js 执行EntryOptionPlugin 中注册的make钩子 执行compi ...

  10. 使用react全家桶制作博客后台管理系统 网站PWA升级 移动端常见问题处理 循序渐进学.Net Core Web Api开发系列【4】:前端访问WebApi [Abp 源码分析]四、模块配置 [Abp 源码分析]三、依赖注入

    使用react全家桶制作博客后台管理系统   前面的话 笔者在做一个完整的博客上线项目,包括前台.后台.后端接口和服务器配置.本文将详细介绍使用react全家桶制作的博客后台管理系统 概述 该项目是基 ...

随机推荐

  1. # 2019-2020-3 《Java 程序设计》第三周总结

    2019-2020-3 <Java 程序设计>第三周知识总结 1.类的定义 语法格式如下(加[]表示可选项): [修饰符] class 类名 { 属性定义(声明) 方法定义(声明)} 2. ...

  2. str相关操作

    大小写转换:*——记住 * upper() 全大写 title() 首字母大写(只要是不属于英文字母的都是分隔符) 切来切去: center(10,'*') 强行用*在原字符串左右两端拼接,拼接成十个 ...

  3. Django积木块一——验证码

    验证码 在github中搜验证码,那个有使用文档 # pip install django-simple-captcha==0.4.6 # setting app captcha # url url( ...

  4. Hadoop 系列文章(一) Hadoop 的安装,以及 Standalone Operation 的启动模式测试

    以前都是玩 java,没搞过 hadoop,所以以此系列文章来记录下学习过程 安装的文件版本.操作系统说明 centos-6.5-x86_64 [bamboo@hadoop-senior opt]$ ...

  5. 背水一战 Windows 10 (63) - 控件(WebView): 基础知识, 加载 html, http, https, ms-appx-web:///, embedded resource, ms-appdata:///, ms-local-stream://

    [源码下载] 背水一战 Windows 10 (63) - 控件(WebView): 基础知识, 加载 html, http, https, ms-appx-web:///, embedded res ...

  6. 构建一个Gods Eye Android应用程序:第1部分 – 收集已安装的Android应用程序

    首先问候一下我的黑客伙伴们,在之前的Introduction to Amunet 教程中,我们了解到Amunet可能是一个间谍Android应用程序. 我不浪费太多时间因而直入主题. 在本教程中,我们 ...

  7. 第二十一节:Java语言基础-关键字,标识符,注释,常量和变量,运算符

    Java语言基础-关键字,标识符,注解,常量和变量,运算符 class Demo { public static void main(String[] args){ System.out.printl ...

  8. Java线程池种类、区别和适用场景

    newCachedThreadPool: 底层:返回ThreadPoolExecutor实例,corePoolSize为0:maximumPoolSize为Integer.MAX_VALUE:keep ...

  9. saltstack 初始化LINUX系统

    前面我们已经了解了saltstack的基础功能,现在就可以使用saltstack为初始化新安装的linux系统. 初始化列表: 1.关闭selinux 3.修改sshd配置文件 4.内核优化 5.ul ...

  10. Screen会话命令 Linux

    由于经常在服务器上运行程序,本地不可能一直和服务器保持连接,而且如果本地和服务器的连接断开,在服务器上运行的程序将会终止,为了,查找了一些网络资料,发现screen 会话命令可以保持本地和服务器断开后 ...