J'essaie de résumer mes connaissances sur les gestionnaires de packages JavaScript, les regroupeurs et les exécuteurs de tâches les plus populaires. Corrigez-moi si j'ai tort, s'il-vous plait:
npm
&bower
sont des gestionnaires de packages. Ils téléchargent simplement les dépendances et ne savent pas comment créer des projets par eux-mêmes. Ce qu'ils savent, c'est appelerwebpack
/gulp
/grunt
après avoir récupéré toutes les dépendances.bower
est commenpm
, mais construit des arbres de dépendance aplatis (contrairement ànpm
ce qui le fait récursivement). La significationnpm
récupère les dépendances pour chaque dépendance (peut les récupérer plusieurs fois), tandisbower
que vous attendez que vous incluiez manuellement les sous-dépendances. Parfoisbower
etnpm
sont utilisés ensemble pour le front-end et le back-end respectivement (puisque chaque mégaoctet peut avoir de l'importance dans le front-end).grunt
etgulp
sont des exécuteurs de tâches pour automatiser tout ce qui peut être automatisé (c'est-à-dire compiler CSS / Sass, optimiser les images, créer un bundle et le réduire / transpiler).grunt
vsgulp
(c'est commemaven
vsgradle
ou configuration vs code). Grunt est basé sur la configuration de tâches indépendantes distinctes, chaque tâche ouvre / gère / ferme le fichier. Gulp nécessite moins de code et est basé sur les flux de nœuds, ce qui lui permet de créer des chaînes de tuyaux (sans rouvrir le même fichier) et le rend plus rapide.webpack
(webpack-dev-server
) - pour moi, c'est un gestionnaire de tâches avec rechargement à chaud des modifications qui vous permet d'oublier tous les observateurs JS / CSS.npm
Lesbower
plugins / + peuvent remplacer les exécuteurs de tâches. Leurs capacités se croisent souvent, il y a donc différentes implications si vous devez utilisergulp
/grunt
overnpm
+ plugins. Mais les exécuteurs de tâches sont nettement meilleurs pour les tâches complexes (par exemple "sur chaque build, créez un bundle, transpilez d'ES6 en ES5, exécutez-le sur tous les émulateurs de navigateurs, faites des captures d'écran et déployez-le sur dropbox via ftp").browserify
permet d'empaqueter des modules de nœuds pour les navigateurs.browserify
vsnode
« srequire
est en fait AMD vs CommonJS .
Des questions:
- Qu'est-ce que
webpack
&webpack-dev-server
? La documentation officielle dit que c'est un bundle de modules mais pour moi, c'est juste un gestionnaire de tâches. Quelle est la différence? - Où utiliseriez-vous
browserify
? Ne pouvons-nous pas faire de même avec les importations de nœuds / ES6? - Quand utiliseriez-vous
gulp
/grunt
overnpm
+ plugins? - Veuillez fournir des exemples lorsque vous devez utiliser une combinaison
Réponses:
Webpack et Browserify
Webpack et Browserify font à peu près la même tâche, qui consiste à traiter votre code à utiliser dans un environnement cible (principalement un navigateur, bien que vous puissiez cibler d'autres environnements comme Node). Le résultat d'un tel traitement est un ou plusieurs scripts assemblés par paquets adaptés à l'environnement ciblé.
Par exemple, disons que vous avez écrit du code ES6 divisé en modules et que vous souhaitez pouvoir l'exécuter dans un navigateur. Si ces modules sont des modules Node, le navigateur ne les comprendra pas car ils n'existent que dans l'environnement Node. Les modules ES6 ne fonctionneront pas non plus dans les anciens navigateurs comme IE11. De plus, vous avez peut-être utilisé des fonctionnalités de langage expérimentales (propositions ES suivantes) que les navigateurs n'implémentent pas encore, donc l'exécution d'un tel script ne ferait que générer des erreurs. Des outils comme Webpack et Browserify résolvent ces problèmes en traduisant ce code dans un formulaire qu'un navigateur est capable d'exécuter . En plus de cela, ils permettent d'appliquer une grande variété d'optimisations sur ces bundles.
Cependant, Webpack et Browserify diffèrent à bien des égards, Webpack propose de nombreux outils par défaut (par exemple, le fractionnement de code), tandis que Browserify ne peut le faire qu'après avoir téléchargé des plugins, mais l' utilisation des deux conduit à des résultats très similaires . Cela se résume à des préférences personnelles (Webpack est plus tendance). Btw, Webpack n'est pas un runner de tâche, c'est juste un processeur de vos fichiers (il les traite par des soi-disant chargeurs et plugins) et il peut être exécuté (entre autres) par un runner de tâche.
Webpack Dev Server
Webpack Dev Server fournit une solution similaire à Browsersync - un serveur de développement où vous pouvez déployer votre application rapidement pendant que vous travaillez dessus et vérifier immédiatement la progression de votre développement, le serveur de développement actualisant automatiquement le navigateur lors des modifications de code ou même propageant le code modifié au navigateur sans recharger avec ce qu'on appelle le remplacement à chaud du module.
Lecteurs de tâches vs scripts NPM
J'ai utilisé Gulp pour sa concision et sa facilité d'écriture des tâches, mais j'ai découvert plus tard que je n'avais besoin ni de Gulp ni de Grunt. Tout ce dont j'avais besoin aurait pu être fait à l'aide de scripts NPM pour exécuter des outils tiers via leur API. Le choix entre les scripts Gulp, Grunt ou NPM dépend du goût et de l'expérience de votre équipe.
Bien que les tâches dans Gulp ou Grunt soient faciles à lire, même pour les personnes peu familiarisées avec JS, c'est un autre outil à exiger et à apprendre et je préfère personnellement réduire mes dépendances et simplifier les choses. D'un autre côté, remplacer ces tâches par la combinaison de scripts NPM et (proprement JS) qui exécutent ces outils tiers (par exemple, le script de nœud configurant et exécutant rimraf à des fins de nettoyage) pourrait être plus difficile. Mais dans la majorité des cas, ces trois sont égaux en termes de résultats.
Exemples
En ce qui concerne les exemples, je vous suggère de jeter un œil à ce projet de démarrage React , qui vous montre une belle combinaison de scripts NPM et JS couvrant l'ensemble du processus de génération et de déploiement. Vous pouvez trouver ces scripts NPM
package.json
dans le dossier racine, dans une propriété nomméescripts
. Là, vous rencontrerez principalement des commandes commebabel-node tools/run start
. Babel-node est un outil CLI (non destiné à une utilisation en production), qui compile d'abord le fichiertools/run
ES6 (fichier run.js situé dans les outils ) - essentiellement un utilitaire de runner. Ce coureur prend une fonction comme argument et l'exécute, ce qui dans ce cas eststart
- un autre utilitaire (start.js
) responsable du regroupement des fichiers source (client et serveur) et du démarrage du serveur d'applications et de développement (le serveur de développement sera probablement Webpack Dev Server ou Browsersync).Pour parler plus précisément,
start.js
crée des ensembles côté client et côté serveur, démarre un serveur express et après un lancement réussi initialise la synchronisation du navigateur, qui au moment de la rédaction ressemblait à ceci (veuillez vous référer au projet de démarrage de Reaper pour le code le plus récent).La partie importante est
proxy.target
, où ils définissent l'adresse du serveur qu'ils souhaitent proxy, qui pourrait être http: // localhost: 3000 , et Browsersync démarre un serveur en écoutant sur http: // localhost: 3001 , où les actifs générés sont servis avec changement automatique détection et remplacement de module à chaud. Comme vous pouvez le voir, il existe une autre propriété de configurationfiles
avec des fichiers ou des modèles individuels. La synchronisation du navigateur surveille les modifications et recharge le navigateur si certains se produisent, mais comme le dit le commentaire, Webpack se charge de surveiller les sources js par lui-même avec HMR, afin qu'elles coopèrent Là.Maintenant, je n'ai pas d'exemple équivalent d'une telle configuration Grunt ou Gulp, mais avec Gulp (et de façon similaire avec Grunt), vous écririez des tâches individuelles dans gulpfile.js comme
où vous feriez essentiellement à peu près les mêmes choses que dans le kit de démarrage, cette fois avec le gestionnaire de tâches, qui résout certains problèmes pour vous, mais présente ses propres problèmes et certaines difficultés lors de l'apprentissage de l'utilisation, et comme je l'ai dit, le plus vous avez de dépendances, plus cela peut mal tourner. Et c'est la raison pour laquelle j'aime me débarrasser de tels outils.
la source
Mise à jour d'octobre 2018
Si vous n'êtes toujours pas sûr du développement frontal, vous pouvez jeter un coup d'œil à une excellente ressource ici.
https://github.com/kamranahmedse/developer-roadmap
Mise à jour juin 2018
Apprendre le JavaScript moderne est difficile si vous n'y êtes pas allé depuis le début. Si vous êtes le nouveau venu, n'oubliez pas de vérifier cet excellent écrit pour avoir une meilleure vue d'ensemble.
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70
Mise à jour juillet 2017
Récemment, j'ai trouvé un guide très complet de l'équipe Grab sur la façon d'aborder le développement frontal en 2017. Vous pouvez le consulter ci-dessous.
https://github.com/grab/front-end-guide
Je recherche également cela depuis un certain temps car il existe de nombreux outils et chacun d'eux nous profite sous un aspect différent. La communauté est divisée en plusieurs outils comme
Browserify, Webpack, jspm, Grunt and Gulp
. Vous pourriez également en entendre parlerYeoman or Slush
. Ce n'est pas vraiment un problème, c'est juste déroutant pour tous ceux qui essaient de comprendre une voie claire à suivre.Quoi qu'il en soit, je voudrais apporter quelque chose.
1. Gestionnaire de packages
Les gestionnaires de packages simplifient l'installation et la mise à jour des dépendances de projet, qui sont des bibliothèques telles que
jQuery, Bootstrap
:, etc. - tout ce qui est utilisé sur votre site et qui n'est pas écrit par vous.Parcourir tous les sites Web de la bibliothèque, télécharger et décompresser les archives, copier des fichiers dans les projets - tout cela est remplacé par quelques commandes dans le terminal.
NPM
signifie:Node JS package manager
vous aide à gérer toutes les bibliothèques sur lesquelles votre logiciel s'appuie. Vous définiriez vos besoins dans un fichier appelépackage.json
et exécuténpm install
en ligne de commande ... puis BANG, vos packages sont téléchargés et prêts à l'emploi. Peut être utilisé à la fois pour lesfront-end and back-end
bibliothèques.Bower
: pour la gestion des packages front-end, le concept est le même avec NPM. Toutes vos bibliothèques sont stockées dans un fichier nommébower.json
puis exécutéesbower install
dans la ligne de commande.NPM
Tonnelle
Yarn
: Un nouveau gestionnaire de paquets pourJavaScript
publié parFacebook
récemment avec quelques autres avantages par rapport àNPM
. Et avec Yarn, vous pouvez toujours utiliser les deuxNPM
etBower
registre pour récupérer le package. Si vous avez déjà installé un package,yarn
crée une copie en cache qui faciliteoffline package installs
.jspm
: est un gestionnaire de packages pour leSystemJS
chargeur de module universel, construit au-dessus duES6
chargeur de module dynamique . Ce n'est pas un gestionnaire de packages entièrement nouveau avec son propre ensemble de règles, il fonctionne plutôt sur les sources de packages existantes. Hors de la boîte, il fonctionne avecGitHub
etnpm
. Comme la plupart desBower
packages basés sont basés surGitHub
, nous pouvons également installer ces packagesjspm
. Il dispose d'un registre qui répertorie la plupart des packages frontaux couramment utilisés pour une installation plus facile.2. Chargeur / groupage de modules
La plupart des projets de n'importe quelle échelle verront leur code divisé entre plusieurs fichiers. Vous pouvez simplement inclure chaque fichier avec une
<script>
balise individuelle , cependant,<script>
établit une nouvelle connexion http, et pour les petits fichiers - ce qui est un objectif de modularité - le temps pour établir la connexion peut prendre beaucoup plus de temps que le transfert des données. Pendant le téléchargement des scripts, aucun contenu ne peut être modifié sur la page.Par exemple
Par exemple
Les ordinateurs peuvent faire cela mieux que vous, et c'est pourquoi vous devez utiliser un outil pour tout regrouper automatiquement dans un seul fichier.
Ensuite , nous avons entendu parler
RequireJS
,Browserify
,Webpack
etSystemJS
RequireJS
: est unJavaScript
chargeur de fichiers et de modules. Il est optimisé pour une utilisation dans le navigateur, mais il peut être utilisé dans d'autres environnements JavaScript, commeNode
.Par exemple: myModule.js
Dans
main.js
, nous pouvons importer enmyModule.js
tant que dépendance et l'utiliser.Et puis dans notre
HTML
, nous pouvons nous référer à utiliser avecRequireJS
.Browserify
: conçu pour permettre l'utilisation deCommonJS
modules formatés dans le navigateur. Par conséquent, ceBrowserify
n'est pas autant un chargeur de module qu'un bundle de module:Browserify
c'est entièrement un outil de construction, produisant un paquet de code qui peut ensuite être chargé côté client.Commencez avec une machine de génération sur laquelle node & npm est installé et obtenez le package:
Écrivez vos modules au
CommonJS
formatEt lorsque vous êtes satisfait, lancez la commande pour regrouper:
Browserify recherche récursivement toutes les dépendances du point d'entrée et les assemble dans un seul fichier:
Webpack
: Il regroupe tous vos actifs statiques, y compris lesJavaScript
images, CSS et plus, dans un seul fichier. Il vous permet également de traiter les fichiers via différents types de chargeurs. Vous pouvez écrire votre syntaxeJavaScript
avecCommonJS
ouAMD
modules. Il s'attaque au problème de construction d'une manière fondamentalement plus intégrée et réfléchie. DansBrowserify
vous utilisezGulp/Grunt
et une longue liste de transformations et de plugins pour faire le travail.Webpack
offre suffisamment de puissance hors de la boîte dont vous n'avez généralement pas besoinGrunt
ou pasGulp
du tout.L'utilisation de base est plus que simple. Installez Webpack comme Browserify:
Et passez la commande un point d'entrée et un fichier de sortie:
SystemJS
: est un chargeur de modules qui peut importer des modules au moment de l'exécution dans l'un des formats populaires utilisés aujourd'hui (CommonJS, UMD, AMD, ES6
). Il est construit au-dessus duES6
polyfill du chargeur de modules et est suffisamment intelligent pour détecter le format utilisé et le gérer de manière appropriée.SystemJS
peut également transpiler du code ES6 (avecBabel
ouTraceur
) ou d'autres langues telles queTypeScript
et enCoffeeScript
utilisant des plugins.3. Gestionnaire de tâches
Les exécuteurs de tâches et les outils de génération sont principalement des outils de ligne de commande. Pourquoi nous devons les utiliser: En un mot: l' automatisation . Le moins de travail que vous avez à faire lors de l'exécution de tâches répétitives telles que la minification, la compilation, les tests unitaires, les peluches qui nous coûtaient auparavant beaucoup de temps en ligne de commande ou même manuellement.
Grunt
: Vous pouvez créer une automatisation pour votre environnement de développement pour prétraiter des codes ou créer des scripts de construction avec un fichier de configuration et il semble très difficile de gérer une tâche complexe. Populaire ces dernières années.Chaque tâche
Grunt
est un tableau de configurations de plugins différentes, qui sont simplement exécutées les unes après les autres, de manière strictement indépendante et séquentielle.Gulp
: L'automatisation,Grunt
mais au lieu de configurations, vous pouvez écrireJavaScript
avec des flux comme s'il s'agissait d'une application de nœud. Préférez ces jours-ci.Il s'agit d'un
Gulp
exemple de déclaration de tâche.4. Outils d'échafaudage
Slush and Yeoman
: Vous pouvez créer des projets de démarrage avec eux. Par exemple, vous prévoyez de construire un prototype avec HTML et SCSS, puis au lieu de créer manuellement un dossier comme scss, css, img, fonts. Vous pouvez simplement installeryeoman
et exécuter un script simple. Alors tout ici pour vous.Trouvez plus ici .
Ma réponse ne correspond pas vraiment au contenu de la question, mais lorsque je recherche ces connaissances sur Google, je vois toujours la question en haut de sorte que j'ai décidé d'y répondre en résumé. J'espère que vous l'avez trouvé utile.
la source
OK, ils ont tous des similitudes, ils font les mêmes choses pour vous de manière différente et similaire, je les divise en 3 groupes principaux comme ci-dessous:
1) Groupeurs de modules
webpack et browserify en tant que populaires, fonctionnent comme des exécuteurs de tâches mais avec plus de flexibilité, de plus, il regroupera tout comme votre paramètre, vous pouvez donc pointer le résultat sous la forme bundle.js par exemple dans un seul fichier, y compris le CSS et Javascript, pour plus de détails sur chacun, regardez les détails ci-dessous:
webpack
plus ici
browserify
plus ici
2) Lecteurs de tâches
gulp et grunt sont des exécuteurs de tâches, essentiellement ce qu'ils font, créant des tâches et les exécutant quand vous le souhaitez, par exemple, vous installez un plugin pour réduire votre CSS, puis vous l'exécutez à chaque fois pour effectuer une réduction, plus de détails sur chacun:
gorgée
plus ici
grognement
plus ici
3) Gestionnaires de packages
les gestionnaires de paquets, ce qu'ils font, c'est gérer les plugins dont vous avez besoin dans votre application et les installer pour vous via github, etc. en utilisant package.json, très pratique pour mettre à jour vos modules, les installer et partager votre application, plus de détails pour chacun:
npm
plus ici
tonnelle
plus ici
et le gestionnaire de paquets le plus récent à ne pas manquer, il est jeune et rapide dans un environnement de travail réel comparé à npm que j'utilisais principalement avant, pour réinstaller les modules, il vérifie le dossier node_modules pour vérifier l'existence du module, semble également installer les modules prend moins de temps:
fil
plus ici
la source
Vous pouvez trouver une comparaison technique sur npmcompare
Comparaison de Browserify, Grunt, Gulp et Webpack
Comme vous pouvez le voir, le webpack est très bien entretenu avec une nouvelle version qui sort tous les 4 jours en moyenne. Mais Gulp semble avoir la plus grande communauté de tous (avec plus de 20 000 étoiles sur Github) Grunt semble un peu négligé (par rapport aux autres)
Donc, si besoin de choisir l'un plutôt que l'autre, j'irais avec Gulp
la source
Une petite note sur npm: npm3 essaie d'installer les dépendances de manière plate
https://docs.npmjs.com/how-npm-works/npm3#npm-v3-dependency-resolution
la source
dedupe
possibilité de faire la même chosewebpack-dev-server est un serveur Web de rechargement en direct que les développeurs Webpack utilisent pour obtenir une rétroaction immédiate sur ce qu'ils font. Il ne doit être utilisé que pendant le développement.
Ce projet est fortement inspiré de l' outil de test unitaire nof5 .
Webpack, comme son nom l'indique, créera un âge de pack UNIQUE pour le Web . Le package sera minimisé et combiné en un seul fichier (nous vivons toujours à l'ère HTTP 1.1). Webpack fait la magie de combiner les ressources (JavaScript, CSS, images) et de les injecter comme ceci: .
<script src="assets/bundle.js"></script>
Il peut également être appelé module de regroupement, car il doit comprendre les dépendances de module et savoir comment saisir les dépendances et les regrouper.
Vous pouvez utiliser Browserify sur les mêmes tâches que celles que vous utiliseriez pour Webpack . - Webpack est cependant plus compact.
Notez que les fonctionnalités du chargeur de module ES6 dans Webpack2 utilisent System.import , qui n'est pris en charge par aucun navigateur de manière native.
Vous pouvez oublier Gulp, Grunt, Brokoli, Brunch et Bower . Utilisez directement les scripts de ligne de commande npm à la place et vous pouvez éliminer des packages supplémentaires comme ceux-ci ici pour Gulp :
Vous pouvez probablement utiliser les générateurs de fichiers de configuration Gulp et Grunt lors de la création de fichiers de configuration pour votre projet. De cette façon, vous n'avez pas besoin d'installer Yeoman ou des outils similaires.
la source
Yarn est un gestionnaire de paquets récent qui mérite probablement d'être mentionné.
Alors, le voici: https://yarnpkg.com/
Pour autant que je sache, il peut récupérer les dépendances npm et bower et possède d'autres fonctionnalités appréciées.
la source
Webpack
est un bundler. CommeBrowserfy
il regarde dans la base de code pour les requêtes de module (require
ouimport
) et les résout récursivement. De plus, vous pouvez configurerWebpack
pour résoudre non seulement les modules de type JavaScript, mais CSS, images, HTML, littéralement tout. Ce qui me passionne particulièrementWebpack
, vous pouvez combiner des modules compilés et chargés dynamiquement dans la même application. Ainsi, on obtient une véritable amélioration des performances, en particulier sur HTTP / 1.x. Comment vous le faites-vous exactement? J'ai décrit des exemples ici http://dsheiko.com/weblog/state-of-javascript-modules-2017/ Comme alternative au bundler, on peut penser àRollup.js
( https://rollupjs.org/ ) , qui optimise le code lors de la compilation, mais supprime tous les morceaux inutilisés trouvés.Car
AMD
, au lieu d'RequireJS
un peut aller avec natifES2016 module system
, mais chargé avecSystem.js
( https://github.com/systemjs/systemjs )En outre, je voudrais souligner qu'il
npm
est souvent utilisé comme outil d'automatisation commegrunt
ougulp
. Consultez https://docs.npmjs.com/misc/scripts . Personnellement, je vais maintenant avec des scripts npm en évitant uniquement d'autres outils d'automatisation, bien que dans le passé j'étais très intérességrunt
. Avec d'autres outils, vous devez compter sur d'innombrables plugins pour les packages, qui ne sont souvent pas bien écrits et ne sont pas activement maintenus.npm
connaît ses packages, vous appelez donc l'un des packages installés localement par son nom, comme:En fait, vous n'avez généralement pas besoin de plug-in si le package prend en charge CLI.
la source