Almost all build systems choose to use the watch mechanism to solve the problem of repeatedly generating post-build files during development. However, under the watch mechanism, we have to endure the problem of modifying the code for a long time, and having to drink a sip of tea after saving the code before refreshing and seeing the effect. Here we try to explore why watch is not a silver bullet and try to find a better solution to this problem.
Facts based on watch
When a file is modified, we can know the file modifications that may be caused by its modification, so just rebuild these files.
Usually, for file A, the corresponding relationship is very accurate in constructing a scenario like file B. 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 rerunning the construction task, because many files may refer to file B.
Unless we build a dependency tree and update the dependency tree every time the file is updated, and trigger file building based on the new dependency tree. But this requires every plug-in to implement this mechanism by itself and is extremely error-prone. Therefore, in fact, the watch mechanism just reruns the entire task. So as the project gets bigger, the watch mechanism will become slower and slower (because more and more files need to rerun the entire process, even if the cache is reduced by reducing the time required for the entire process).
Solution
src is available directly
AlloyTeam & @ldjking, simply put src directly and put the build tasks on the browser side, or even not build at all. It can not only modify and refresh in time, but also reduce time consumption during the development process. Offline construction is only responsible for performance optimization issues and not for development efficiency.
Typical representatives include LESS, React, etc. But there are some problems:
It is difficult to implement elegant construction methods on the browser side, and it is difficult to provide powerful functions to further reduce development costs. Most of them can only introduce scripts in a similar way to <style type="text/less"></style> way.
The execution order in development mode is not necessarily the same as the actual scenario, which may lead to invisible bugs. For example, implementing an HTML inline is asynchronous, but in the release mode is synchronized, resulting in inexplicable bugs.
The browser compilation performance is worrying, such as the JS version of sass, and the compilation speed is almost unbearable.
It is necessary to maintain two sets of online and offline construction systems, which increases the cost of tool development.
Dynamic construction of local server
One fact is: with reasonable specification support, we can go back to the entry file requested by the browser to the file that was built during the file. This way we can dynamically trigger a build process.
By establishing a server locally, let the server capture the request and build it dynamically in the server. As long as we go back to the entry file, we can throw the entry file into the pipeline composed of gulp plug-in, and the output is the file required by the browser.
This way we can solve all the above problems.