node.js中watch机制详解(nodejs worker)

编辑：rootadmin

推荐整理分享node.js中watch机制详解(nodejs worker)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:node.js gui,node.js gui,nodejs worker,nodejs watch,nodejs watch,node.js in action,node watch,node-watch,内容如对您有帮助，希望把文章链接给更多的朋友！

几乎所有构建系统都选择使用watch机制来解决开发过程中需要反复生成构建后文件的问题，但在watch机制下，长期以来我们必须忍受修改完代码，保存完代码必须喝口茶才能刷新看看效果的问题。在这里我们尝试探讨为什么watch不是银弹，并尝试寻找一种更好的方案来解决这个问题。

watch基于的事实

当一个文件修改，我们能知道其修改可能导致的文件修改，那么重新构建这些文件即可。

通常对于文件A，构建成文件B这种场景，这种对应关系是极好确定的。但现实场景下，构建过程往往不是那么简单。例如：

文件A ＋文件B（被文件A引用）－> 文件C在这种场景下，文件B的修改，可能难以定位哪些文件需要重新跑构建任务，因为可能有很多文件引用了文件B。

除非我们建立一个依赖树，并在每次文件更新的情况下更新依赖树，并根据新的依赖树触发文件构建。但这对每一个插件都需要自行实现这个机制，并且极易出错。故实际上watch机制仅仅是重跑了整个task。所以当项目越来越大的时候，watch机制将越来越慢（因为越来越多文件需要重新跑整个过程，即使通过缓存减少了整个过程所需的耗时）。

解决方案

src直接可用

AlloyTeam & @ldjking，简单来说直接让src直接可跑，把构建任务放置在浏览器端，甚至根本不构建，既可做到及时修改及时刷新，在开发过程中减少了时间消耗。线下构建仅仅负责性能优化上的问题，不负责开发效率。典型代表有LESS、React等。但也有一些问题：

难以在浏览器端实现优雅的构建方式，难以提供强大的功能进一步减少开发成本，大部分只能采用类似<style type="text/less"></style>的方式引入脚本。开发模式下的执行顺序不一定和实际场景相同，可能导致隐形bug出现，例如实现一个HTML inline由于开发模式下inline是异步的，而发布模式下inline时同步的，产生莫名其妙的bug。浏览器编译性能堪忧，例如js版的sass，编译速度几乎无法忍受。需要维护线上、线下两套构建系统，增加了工具开发成本。本地服务器动态构建

一个事实是：在合理的规范支持下，我们可以从浏览器请求的文件，回溯到该文件构建过程中的入口文件。这样我们就可以动态触发一次构建过程。

通过在本地建立一个服务器，让服务器捕获请求后，在服务器中动态构建。只要回溯到入口文件，我们便能将入口文件丢进gulp插件组成的管道中，则输出便是浏览器需要的文件。

这样我们就能解决上面的所有问题。

nodejs开发环境配置与使用先说下nodejs这个哦，有人以为它是一种语言，其实不是，它是一个平台，一个建立在google的V8引擎上的js运行平台，就是解析js，并提供自己的一些API给

nodejs 提示‘xxx’ 不是内部或外部命令解决方法一般出现这样的问题原因是npm安装出现了问题，全局模块目录没有被添加到系统环境变量。Windows用户检查下npm的目录是否加入了系统变量PATH中，如果不

node.js使用npm 安装插件时提示install Error: ENOENT报错的解决方法在使用npminstall安装扩展插件时，系统提示npminstallError:ENOENT,stat'C:Users用户名AppDataRoamingnpm'。以前都是很顺利的安装过程，没出现这种情况。我这里的解