Detailed explanation of watch mechanism in node.js

  • 2020-03-30 04:18:30
  • OfStack

Almost all build systems choose to use the watch mechanism to solve the problem of repeatedly generating the built files during the development process, but under the watch mechanism, we have to endure for a long time to modify the code, save the code must drink tea before refreshing to see the effect. Here we try to explore why watch is not a silver bullet, and try to find a better solution to this problem.

Watch is based on facts

When a file is modified, we can know how much the change might cause, so we can rebuild the files.

In general, for file A, build file B scenarios, this correspondence is extremely well defined. But in the real world, the build process is often not so simple. Such as:

Document A + document B (referenced by document A) -> The file C
In this scenario, changes to file B may make it difficult to locate which files need to rerun the build task, because there may be many files that reference file B.

Unless we create a dependency tree, update the dependency tree with each file update, and trigger a file build based on the new dependency tree. However, each plug-in needs to implement this mechanism on its own, and it is highly error-prone. Therefore, the watch mechanism only reruns the entire task. So as the project gets bigger, the watch mechanism will get slower and slower (because more and more files need to reroute the whole process, even though caching reduces the time required for the whole process).

The solution

SRC is available directly

AlloyTeam & @ldjking, simply make SRC run, put build tasks on the browser side, or not build at all, so that it can be timely modified and refreshed, reducing time consumption during development. Offline builds are only responsible for performance optimization, not development efficiency.
Typical representatives are LESS, React, etc. But there are some problems:

It is difficult to achieve an elegant way of building on the browser side and to provide powerful functions to further reduce the development cost. Style type = "text/less" > < / style> The way to introduce scripts.
The execution order in the development mode may not be the same as the actual scenario, which may cause invisible bugs, such as the implementation of an HTML inline because the inline in the development mode is asynchronous, while the inline in the publishing mode is synchronous, causing a puzzling bug.
Browser compilation performance, such as the js version of sass, compilation speed is almost unbearable.
The need to maintain both online and offline build systems increases the cost of tool development.
Local server dynamic build

By setting up a server locally, you let the server capture the request and build it dynamically on the server. Simply by going back to the entry file, we can drop the entry file into the gulp plug-in pipeline, and the output is the file the browser needs.

So we can solve all the above problems.


Related articles: