Detailed explanation of watch mechanism in node.js_node.js

Almost all build systems choose to use the watch mechanism to solve the problem of repeatedly generating post-build files during the development process. However, under the watch mechanism, we have to endure modifying the code for a long time. After saving the code, we have to drink tea before refreshing. Look at the effect. Here we try to explore why watches are not a silver bullet and try to find a better solution to this problem.

Facts the watch is based on

When a file is modified, we can know the file modifications that the modification may cause, and then rebuild these files.

Usually for the scenario where file A is constructed into file B, this correspondence is extremely certain. But in real scenarios, the construction process is often not that simple. For example:

File A + File B (referenced by File A) -> File C
In this scenario, when file B is modified, it may be difficult to locate which files need to be re-run the build task, because there may be many files that reference file B.

Unless we build a dependency tree and update the dependency tree every time the file is updated, and trigger the file build based on the new dependency tree. But each plug-in needs to implement this mechanism by itself, and it is extremely error-prone. So in fact the watch mechanism just reruns the entire task. So when the project gets larger and larger, the watch mechanism will become slower and slower (because more and more files need to re-run the entire process, even if the time required for the entire process is reduced through caching).

Solution

src is available directly

AlloyTeam & @ldjking, to put it simply, make src directly runnable, place the construction task on the browser side, or even not build at all. It can be modified and refreshed in time, which reduces time consumption during the development process. Offline construction is only responsible for performance optimization issues, not development efficiency.
Typical representatives include LESS, React, etc. But there are also some problems:

It is difficult to implement an elegant construction method on the browser side, and it is difficult to provide powerful functions to further reduce development costs. Most of them can only be introduced in a way similar to script.
The execution order in development mode is not necessarily the same as the actual scenario, which may lead to invisible bugs. For example, when implementing an HTML inline, inline is asynchronous in development mode, while inline in release mode is synchronous, resulting in inexplicable bugs.
The compilation performance of browsers is worrying. For example, the compilation speed of the js version of sass is almost unbearable.
It is necessary to maintain two sets of online and offline construction systems, which increases the cost of tool development.
Local server dynamic build

One fact is: with the support of reasonable specifications, we can trace back the file requested by the browser to the entry file in the file construction process. This way we can trigger a build process dynamically.

By setting up a server locally, let the server capture the request and build it dynamically in the server. As long as we trace back to the entry file, we can throw the entry file into the pipeline composed of the gulp plug-in, and the output will be the file required by the browser.

This way we can solve all the problems above.