随着前端技术的飞速发展,前端开发也从原始的刀耕火种,向着工程化效率化的方向发展。在各类开发框架以外,打包编译等技术也是层出不穷,开发体验也是愈来愈好。例如HMR,让咱们的更新能够即时可见,告别了手动F5的状况。其实现就是监听文件变化自动调用构建过程。下面就关注下如何实现node监听文件变化。html
假定要监听index.js,每当内容更改从新编译。
咱们就用简单的console来标识执行编译。下面就是实现该功能。前端
翻下node的文档就会看到一个知足咱们需求的Apifs.watchFile(毕竟是文件相关的操做,很大可能就在fs模块下面了)。node
fs.watchFile(filename[, options], listener)
复制代码
filename 显然就是文件名git
options 可选 对象 包含如下两个属性github
listener 事件回调 包含两个参数api
看完参数信息,不知道你们有没有从其参数属性中获得点什么特别的信息。特别是interval选项和listener中的回调参数。bash
监控filename对应文件,每当访问文件时会触发回调。框架
这里每当访问文件时会触发,实际指的是每次切换以后再次进入文件,而后保存以后,不管是否作了修改都会出发回调。函数
另外轮询事件和文件对象,是否是能够猜想,其实现监听的原理,固定时间轮询文件状态,而后将先后的状态返回,将判断交给使用者。
因此node也建议,若是要获取文件修改,那么须要根据stat对象的修改时间来进行对比,即比较 curr.mtime 和 prev.mtime。post
这样就有点问题,咱们先看下例子,会更清晰一点。
const fs = require('fs')
const filePath = './index.js'
console.log(`正在监听 ${filePath}`);
fs.watchFile(filePath, (cur, prv) => {
if (filePath) {
// 打印出修改时间
console.log(`cur.mtime>>${cur.mtime.toLocaleString()}`)
console.log(`prv.mtime>>${prv.mtime.toLocaleString()}`)
// 根据修改时间判断作下区分,以分辨是否更改
if (cur.mtime != prv.mtime){
console.log(`${filePath}文件发生更新`)
}
}
})
复制代码
而后测试结果以下:
// 运行
node watch1.js
// 一、访问index.js 不作修改,而后保存
// 二、切换文件,再次访问,不作修改,只报错
// 三、编辑内容,并保存
复制代码
能够看到一、2两步,并无实际修改内容,然而咱们并无办法区分。只要你是切换以后再保存,修改时间戳mtime就发生变化。
另外响应时间真的很慢,毕竟是轮询。
对于这些问题,其实官网也给了一句话:
Using fs.watch() is more efficient than fs.watchFile and fs.unwatchFile. fs.watch should be used instead of fs.watchFile and fs.unwatchFile when possible.
复制代码
能用fs.watch的状况就不要用watchFile了。一是效率,二是不能准确获知修改状态 三是只能监听单独文件
对于实际开发过程当中,显然咱们想要关注的是源文件夹的变更。
首先用法以下:
fs.watch(filename[, options][, listener])
复制代码
跟fs.watchFile比较相似。
filename 显然就是文件名
options 可选 对象或者字符串 包含如下三个属性
listener 事件回调 包含两个参数
options若是是字符串,指的是encoding。
监听filename对应的文件或者文件夹(recursive参数也体现出来这一特性),返回一个fs.FSWatcher对象。
该功能的实现依赖于底层操做系统的对于文件更改的通知。 因此就存在一个问题,可能不一样平台的实现不太相同。 以下示例1:
const fs = require('fs')
const filePath = './'
console.log(`正在监听 ${filePath}`);
fs.watch(filePath,(event,filename)=>{
if (filename){
console.log(`${filename}文件发生更新`)
}
})
复制代码
一个比较明显的优点就体现出来了:响应比较及时,相比于轮询,效率确定更高。
不过这样修改并保存的时候回发现一样有点问题。 直接保存,显示两次更新
修改文件以后,一样显示两次更新(mac系统上是两次,其余系统可能有所差异) 这样多是于操做系统对文件修改的事件支持有关,在保存的时候出发了不止一次。
下面聚焦于回调事件的参数,event对应事件类型,是否能够判断事件类型为change呢,才执行呢,忽略空保存。
const fs = require('fs')
const filePath = './'
console.log(`正在监听 ${filePath}`);
fs.watch(filePath,(event,filename)=>{
console.log(`event类型${event}`)
if (filename && event == 'change') {
console.log(`${filename}文件发生更新`)
}
})
复制代码
不过实际上,空的保存event也是change,另外不一样平台event的实现可能也有所不一样。这种方式要pass掉。
显然从上面的例子能够看到,变动时间依然不可控。由于每次保存,node对应stat对象依然会修改。
只能选择这种方式来判断是不是否更新。例如md5:
const fs = require('fs'),
md5 = require('md5');
const filePath = './'
let preveMd5 = null
console.log(`正在监听 ${filePath}`);
fs.watch(filePath,(event,filename)=>{
var currentMd5 = md5(fs.readFileSync(filePath + filename))
if (currentMd5 == preveMd5) {
return
}
preveMd5 = currentMd5
console.log(`${filePath}文件发生更新`)
})
复制代码
先保存当前文件md5值,每次文件变化时(即保存操做响应以后),每次都获取文件的md5而后进行对比,看是否发生变化。
不过这样能够看到,当初次保存时,都会执行一次,由于初始值为null的缘故。这样能够加个兼容,根据是否第一次保存来判断好了。
对于不一样的操做系统,可能保存时触发的回调不止一个(mac上到没出现)。为了不这种实时响应对应的频繁触发,能够引入debounce函数来保证性能。
const fs = require('fs'),
md5 = require('md5');
let preveMd5 = null,
fsWait = false
const filePath = './'
console.log(`正在监听 ${filePath}`);
fs.watch(filePath,(event,filename)=>{
if (filename){
if (fsWait) return;
fsWait = setTimeout(() => {
fsWait = false;
}, 100)
var currentMd5 = md5(fs.readFileSync(filePath + filename))
if (currentMd5 == preveMd5){
return
}
preveMd5 = currentMd5
console.log(`${filePath}文件发生更新`)
}
})
复制代码
到这里,node监听文件的实现就结束了。作个学习笔记,来作个参考记录。实现起来并不难,可是要实际应用的话须要考虑的方面就比较多了。仍是推荐开源框架node-watch、chokidar等,各方面实现的都比较完善。更多请转个人博客
node文档
How to Watch for Files Changes in Node.js
Nodejs Monitor File Changes