Explication détaillée du mécanisme de montre dans node.js_node.js

Presque tous les systèmes de build choisissent d'utiliser le mécanisme de surveillance pour résoudre le problème de la génération répétée de fichiers post-build pendant le processus de développement. Cependant, dans le cadre du mécanisme de surveillance, nous devons supporter de modifier le code pendant une longue période après l'enregistrement. le code, il faut boire du thé avant de se rafraîchir. Regardez l'effet. Nous essayons ici d’explorer pourquoi les montres ne sont pas une solution miracle et de trouver une meilleure solution à ce problème.

Faits sur lesquels la montre est basée

Lorsqu'un fichier est modifié, nous pouvons connaître les modifications de fichiers que la modification peut entraîner, puis reconstruire ces fichiers.

Habituellement, pour le scénario où le fichier A est construit dans le fichier B, cette correspondance est extrêmement certaine. Mais dans les scénarios réels, le processus de construction n’est souvent pas aussi simple. Par exemple :

Fichier A + Fichier B (référencé par Fichier A) -> Fichier C
Dans ce scénario, lorsque le fichier B est modifié, il peut être difficile de localiser les fichiers qui doivent être réexécutés par la tâche de génération, car de nombreux fichiers peuvent faire référence au fichier B.

À moins que nous créions un arbre de dépendances et que nous mettions à jour l'arbre de dépendances à chaque fois que le fichier est mis à jour, et que nous déclenchions la construction du fichier en fonction du nouvel arbre de dépendances. Mais chaque plug-in doit implémenter ce mécanisme par lui-même, et il est extrêmement sujet aux erreurs. En fait, le mécanisme de la montre relance simplement l’intégralité de la tâche. Ainsi, lorsque le projet devient de plus en plus volumineux, le mécanisme de surveillance deviendra de plus en plus lent (car de plus en plus de fichiers doivent réexécuter l'intégralité du processus, même si le temps requis pour l'ensemble du processus est réduit grâce à la mise en cache).

Solution

src est disponible directement

AlloyTeam & @ldjking, pour faire simple, rendent src directement exécutable, placent la tâche de construction côté navigateur, ou même ne pas construire du tout. Elle peut être modifiée et actualisée à temps, ce qui réduit la consommation de temps lors du développement. processus. La construction hors ligne n'est responsable que des problèmes d'optimisation des performances, pas de l'efficacité du développement.
Les représentants typiques incluent LESS, React, etc. Mais il y a aussi quelques problèmes :

Il est difficile de mettre en œuvre une méthode de construction élégante côté navigateur, et il est difficile de fournir des fonctions puissantes pour réduire davantage les coûts de développement. La plupart d'entre elles ne peuvent être introduites que d'une manière similaire à script.
L'ordre d'exécution en mode développement n'est pas nécessairement le même que le scénario réel, ce qui peut conduire à des bugs invisibles. Par exemple, lors de l'implémentation d'un HTML en ligne, l'inline est asynchrone en mode développement, tandis que l'inline en mode release est synchrone, ce qui entraîne des problèmes inexplicables. insectes.
Les performances de compilation des navigateurs sont inquiétantes. Par exemple, la vitesse de compilation de la version js de sass est presque insupportable.
Il est nécessaire de maintenir deux ensembles de systèmes de construction en ligne et hors ligne, ce qui augmente le coût de développement des outils.
Construction dynamique du serveur local

Un fait est que : avec le support de spécifications raisonnables, nous pouvons retracer le fichier demandé par le navigateur jusqu'au fichier d'entrée dans le processus de construction du fichier. De cette façon, nous pouvons déclencher un processus de construction de manière dynamique.

En configurant un serveur localement, laissez le serveur capturer la requête et la construire dynamiquement sur le serveur. Tant que nous remontons au fichier d'entrée, nous pouvons jeter le fichier d'entrée dans le pipeline composé du plug-in gulp, et la sortie sera le fichier requis par le navigateur.

De cette façon, nous pouvons résoudre tous les problèmes ci-dessus.