Tout d’abord, pourquoi utiliser Gulp pour compiler ? Lorsqu'il a découvert Webpack pour la première fois, l'intimé a également mis en œuvre le workflow Gulp + Webpack. Il peut fonctionner et être maintenu, mais en fait, cela apporte une complexité inutile. Il n'y a en fait aucune tâche dans le système de construction qui nécessite l'utilisation de Gulp. Dans un projet Gulp + Webpack, deux ensembles de configurations d'empaquetage au niveau d'une centaine de lignes doivent être conservés, ce qui est en fait peu pratique à utiliser. Les fonctions de Gulp peuvent être complètement remplacées par NPM Script, ce qui est également la tendance actuelle. Il est compréhensible que vous souhaitiez maintenir vos connaissances existantes de la pile technologique et que vous souhaitiez introduire Gulp, mais ce n'est pas obligatoire.

Il est recommandé de rationaliser le code et d'implémenter le modèle de configuration de vue + webpack en partant du principe de comprendre la configuration Webpack de vue-cli. La pratique du répondant est qu'un modèle Webpack qui peut répondre aux exigences de taille d'un projet Vue moyen (10 000 lignes) peut être déposé avec un seul config.js, et il n'est même pas nécessaire de faire la distinction entre webpack.dev.js et module webpack.prod.js.

Pour référence, il s'agit du modèle de projet Vue à moyenne échelle de 100 lignes mentionné ci-dessus. La configuration en 100 lignes réalise une prise en charge commune pour HMR, préprocesseur, extraction de dépendances, images en ligne, extraction CSS, génération HTML, proxy inverse, etc. . Fonctions d'ingénierie front-end :
https://github.com/doodlewind...

Voici le modèle Gulpfile du projet Gulp + Webpack :
https://github.com/doodlewind...