NPM contre Bower contre Browserify contre Gulp contre Grunt contre Webpack

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& bowersont 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 appeler webpack/ gulp/ gruntaprès avoir récupéré toutes les dépendances.
• bowerest comme npm, mais construit des arbres de dépendance aplatis (contrairement à npmce qui le fait récursivement). La signification npmrécupère les dépendances pour chaque dépendance (peut les récupérer plusieurs fois), tandis bowerque vous attendez que vous incluiez manuellement les sous-dépendances. Parfois boweret npmsont 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).
• gruntet gulpsont 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).
• gruntvs gulp(c'est comme mavenvs gradleou 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.
• npmLes bowerplugins / + peuvent remplacer les exécuteurs de tâches. Leurs capacités se croisent souvent, il y a donc différentes implications si vous devez utiliser gulp/ gruntover npm+ 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").
• browserifypermet d'empaqueter des modules de nœuds pour les navigateurs. browserifyvs node« s requireest en fait AMD vs CommonJS .

Des questions:

1. 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?
2. Où utiliseriez-vous browserify? Ne pouvons-nous pas faire de même avec les importations de nœuds / ES6?
3. Quand utiliseriez-vous gulp/ gruntover npm+ plugins?
4. Veuillez fournir des exemples lorsque vous devez utiliser une combinaison

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.jsondans le dossier racine, dans une propriété nommée scripts. Là, vous rencontrerez principalement des commandes comme babel-node tools/run start. Babel-node est un outil CLI (non destiné à une utilisation en production), qui compile d'abord le fichier tools/runES6 (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 est start- 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.jscré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).

const bs = Browsersync.create();  
bs.init({
      ...(DEBUG ? {} : { notify: false, ui: false }),

      proxy: {
        target: host,
        middleware: [wpMiddleware, ...hotMiddlewares],
      },

      // no need to watch '*.js' here, webpack will take care of it for us,
      // including full page reloads if HMR won't work
      files: ['build/content/**/*.*'],
}, resolve)

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 configuration filesavec 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

gulp.task('bundle', function() {
  // bundling source files with some gulp plugins like gulp-webpack maybe
});

gulp.task('start', function() {
  // starting server and stuff
});

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.

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 parler Yeoman 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.

• NPMsignifie: Node JS package managervous aide à gérer toutes les bibliothèques sur lesquelles votre logiciel s'appuie. Vous définiriez vos besoins dans un fichier appelé package.jsonet exécuté npm installen ligne de commande ... puis BANG, vos packages sont téléchargés et prêts à l'emploi. Peut être utilisé à la fois pour les front-end and back-endbibliothè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.jsonpuis exécutées bower installdans la ligne de commande.

La plus grande différence entre Boweret NPMest que NPM fait un arbre de dépendance imbriqué tandis que Bower nécessite un arbre de dépendance plat comme ci-dessous.

Citations tirées de Quelle est la différence entre Bower et npm?

NPM

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

Tonnelle

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

Il y a quelques mises à jour sur npm 3 Duplication and Deduplication, veuillez ouvrir le document pour plus de détails.

• Yarn: Un nouveau gestionnaire de paquets pour JavaScript publié par Facebookrécemment avec quelques autres avantages par rapport à NPM. Et avec Yarn, vous pouvez toujours utiliser les deux NPMet Bowerregistre pour récupérer le package. Si vous avez déjà installé un package, yarncrée une copie en cache qui facilite offline package installs.

• jspm: est un gestionnaire de packages pour le SystemJSchargeur de module universel, construit au-dessus du ES6chargeur 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 avec GitHubet npm. Comme la plupart des Bowerpackages basés sont basés sur GitHub, nous pouvons également installer ces packages jspm. Il dispose d'un registre qui répertorie la plupart des packages frontaux couramment utilisés pour une installation plus facile.

Voir la différence entre Boweret jspm: Package Manager: Bower vs jspm

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.

• Le problème du temps de téléchargement peut être largement résolu en concaténant un groupe de modules simples en un seul fichier et en le minimisant.

Par exemple

<head>
    <title>Wagon</title>
    <script src=“build/wagon-bundle.js”></script>
</head>

• Cependant, la performance se fait au détriment de la flexibilité. Si vos modules ont des interdépendances, ce manque de flexibilité peut être un exemple.

Par exemple

<head>
    <title>Skateboard</title>
    <script src=“connectors/axle.js”></script>
    <script src=“frames/board.js”></script>
    <!-- skateboard-wheel and ball-bearing both depend on abstract-rolling-thing -->
    <script src=“rolling-things/abstract-rolling-thing.js”></script>
    <script src=“rolling-things/wheels/skateboard-wheel.js”></script>
    <!-- but if skateboard-wheel also depends on ball-bearing -->
    <!-- then having this script tag here could cause a problem -->
    <script src=“rolling-things/ball-bearing.js”></script>
    <!-- connect wheels to axle and axle to frame -->
    <script src=“vehicles/skateboard/our-sk8bd-init.js”></script>
</head>

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, WebpacketSystemJS

• RequireJS: est un JavaScriptchargeur de fichiers et de modules. Il est optimisé pour une utilisation dans le navigateur, mais il peut être utilisé dans d'autres environnements JavaScript, comme Node.

Par exemple: myModule.js

// package/lib is a dependency we require
define(["package/lib"], function (lib) {

    // behavior for our module
    function foo() {
        lib.log( "hello world!" );
    }

    // export (expose) foo to other modules as foobar
    return {
        foobar: foo
    }
});

Dans main.js, nous pouvons importer en myModule.jstant que dépendance et l'utiliser.

require(["package/myModule"], function(myModule) {
    myModule.foobar();
});

Et puis dans notre HTML, nous pouvons nous référer à utiliser avec RequireJS.

<script src=“app/require.js” data-main=“main.js” ></script>

En savoir plus sur CommonJSet AMDpour comprendre facilement. Relation entre CommonJS, AMD et RequireJS?

• Browserify: conçu pour permettre l'utilisation de CommonJSmodules formatés dans le navigateur. Par conséquent, ce Browserifyn'est pas autant un chargeur de module qu'un bundle de module: Browserifyc'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:

npm install -g –save-dev browserify

Écrivez vos modules au CommonJSformat

//entry-point.js
var foo = require('../foo.js');
console.log(foo(4));

Et lorsque vous êtes satisfait, lancez la commande pour regrouper:

browserify entry-point.js -o bundle-name.js

Browserify recherche récursivement toutes les dépendances du point d'entrée et les assemble dans un seul fichier:

<script src=”bundle-name.js”></script>

• Webpack: Il regroupe tous vos actifs statiques, y compris les JavaScriptimages, 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 syntaxe JavaScriptavec CommonJSou AMDmodules. Il s'attaque au problème de construction d'une manière fondamentalement plus intégrée et réfléchie. Dans Browserifyvous utilisez Gulp/Gruntet une longue liste de transformations et de plugins pour faire le travail. Webpackoffre suffisamment de puissance hors de la boîte dont vous n'avez généralement pas besoin Gruntou pas Gulpdu tout.

L'utilisation de base est plus que simple. Installez Webpack comme Browserify:

npm install -g –save-dev webpack

Et passez la commande un point d'entrée et un fichier de sortie:

webpack ./entry-point.js bundle-name.js

• 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 du ES6polyfill du chargeur de modules et est suffisamment intelligent pour détecter le format utilisé et le gérer de manière appropriée. SystemJSpeut également transpiler du code ES6 (avec Babelou Traceur) ou d'autres langues telles que TypeScriptet en CoffeeScriptutilisant des plugins.

Vous voulez savoir quel est le node moduleet pourquoi il n'est pas bien adapté au navigateur.

Article plus utile:

• https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a0a9#.c1q7ao3h4
• http://jamesknelson.com/which-build-system-should-i-use-for-my-javascript-app/
• https://appendto.com/2016/06/the-short-history-of-javascript-module-loaders/

Pourquoi jspmet SystemJS?

L' un des principaux objectifs de la ES6modularité est de rendre très simple à installer et à utiliser une bibliothèque Javascript où que vous soyez sur Internet ( Github, npm, etc.). Deux choses seulement sont nécessaires:

• Une seule commande pour installer la bibliothèque
• Une seule ligne de code pour importer la bibliothèque et l'utiliser

Donc, avec jspm, vous pouvez le faire.

1. Installez la bibliothèque avec une commande: jspm install jquery
2. Importez la bibliothèque avec une seule ligne de code, pas besoin de référence externe à l'intérieur de votre fichier HTML.

display.js

var $ = require('jquery'); 

$('body').append("I've imported jQuery!");

3. Ensuite, vous configurez ces choses System.config({ ... })avant d'importer votre module. Normalement, lors de l'exécution jspm init, il y aura un fichier nommé config.jsà cet effet.

4. Pour exécuter ces scripts, nous devons charger system.jset config.jssur la page HTML. Après cela, nous chargerons le display.jsfichier à l'aide du SystemJSchargeur de module.

index.html

<script src="jspm_packages/system.js"></script>
<script src="config.js"></script>
<script>
  System.import("scripts/display.js");
</script>

Noté: Vous pouvez également l'utiliser npmavec Webpackcomme Angular 2 l'a appliqué. Depuis a jspmété développé pour s'intégrer à SystemJSet il fonctionne au-dessus de la npmsource existante , donc votre réponse dépend de vous.

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 Gruntest 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.

grunt.initConfig({
  clean: {
    src: ['build/app.js', 'build/vendor.js']
  },

  copy: {
    files: [{
      src: 'build/app.js',
      dest: 'build/dist/app.js'
    }]
  }

  concat: {
    'build/app.js': ['build/vendors.js', 'build/app.js']
  }

  // ... other task configurations ...

});

grunt.registerTask('build', ['clean', 'bower', 'browserify', 'concat', 'copy']);

• Gulp: L'automatisation, Gruntmais au lieu de configurations, vous pouvez écrire JavaScriptavec des flux comme s'il s'agissait d'une application de nœud. Préférez ces jours-ci.

Il s'agit d'un Gulpexemple de déclaration de tâche.

//import the necessary gulp plugins
var gulp = require('gulp');
var sass = require('gulp-sass');
var minifyCss = require('gulp-minify-css');
var rename = require('gulp-rename');

//declare the task
gulp.task('sass', function(done) {
  gulp.src('./scss/ionic.app.scss')
    .pipe(sass())
    .pipe(gulp.dest('./www/css/'))
    .pipe(minifyCss({
      keepSpecialComments: 0
    }))
    .pipe(rename({ extname: '.min.css' }))
    .pipe(gulp.dest('./www/css/'))
    .on('end', done);
});

Voir plus: https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.fte0nahri

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 installer yeomanet exécuter un script simple. Alors tout ici pour vous.

Trouvez plus ici .

npm install -g yo
npm install --global generator-h5bp
yo h5bp

Voir plus: https://www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express

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.

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:

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

webpack est un bundle de modules pour les applications JavaScript modernes. Lorsque webpack traite votre application, il crée récursivement un graphe de dépendances qui inclut tous les modules dont votre application a besoin, puis regroupe tous ces modules dans un petit nombre de bundles - souvent un seul - à charger par le navigateur.

Il est incroyablement configurable, mais pour commencer, il vous suffit de comprendre les quatre concepts fondamentaux: entrée, sortie, chargeurs et plugins.

Ce document est destiné à donner un aperçu de haut niveau de ces concepts, tout en fournissant des liens vers des cas d'utilisation spécifiques à des concepts détaillés.

plus ici

browserify

Browserify est un outil de développement qui nous permet d'écrire des modules de style node.js qui se compilent pour être utilisés dans le navigateur. Tout comme le nœud, nous écrivons nos modules dans des fichiers séparés, en exportant les méthodes et propriétés externes à l'aide des variables module.exports et exports. Nous pouvons même exiger d'autres modules en utilisant la fonction require, et si nous omettons le chemin relatif, il sera résolu vers le module dans le répertoire node_modules.

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

gulp.js est une boîte à outils JavaScript open source de Fractal Innovations et de la communauté open source de GitHub, utilisée comme système de génération de streaming dans le développement Web frontal. Il s'agit d'un gestionnaire de tâches basé sur Node.js et Node Package Manager (npm), utilisé pour l'automatisation des tâches chronophages et répétitives impliquées dans le développement Web telles que la minification, la concaténation, le contournement du cache, les tests unitaires, les peluches, l'optimisation, etc. une approche par code sur configuration pour définir ses tâches et s'appuie sur ses petits plugins à usage unique pour les exécuter. l'écosystème gulp propose plus de 1000 plugins de ce type.

plus ici

grognement

Grunt est un exécuteur de tâches JavaScript, un outil utilisé pour effectuer automatiquement des tâches fréquemment utilisées telles que la minification, la compilation, les tests unitaires, le linting, etc. Il utilise une interface de ligne de commande pour exécuter des tâches personnalisées définies dans un fichier (appelé Gruntfile) . Grunt a été créé par Ben Alman et est écrit en Node.js. Il est distribué via npm. Actuellement, plus de cinq mille plugins sont disponibles dans l'écosystème Grunt.

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

npm est un gestionnaire de packages pour le langage de programmation JavaScript. Il s'agit du gestionnaire de packages par défaut pour l'environnement d'exécution JavaScript Node.js. Il se compose d'un client de ligne de commande, également appelé npm, et d'une base de données en ligne de packages publics, appelée registre npm. Le registre est accessible via le client, et les packages disponibles peuvent être consultés et recherchés via le site Web npm.

plus ici

tonnelle

Bower peut gérer des composants contenant du HTML, du CSS, du JavaScript, des polices ou même des fichiers image. Bower ne concatène pas, ne minimise pas le code ou ne fait rien d'autre - il installe simplement les bonnes versions des packages dont vous avez besoin et leurs dépendances. Pour commencer, Bower fonctionne en récupérant et en installant des packages de partout, en s'occupant de la chasse, de la recherche, du téléchargement et de l'enregistrement des éléments que vous recherchez. Bower garde une trace de ces packages dans un fichier manifeste, bower.json.

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

Yarn est un gestionnaire de packages pour votre code. Il vous permet d'utiliser et de partager du code avec d'autres développeurs du monde entier. Le fil le fait rapidement, en toute sécurité et de manière fiable afin que vous n'ayez jamais à vous inquiéter.

Yarn vous permet d'utiliser les solutions d'autres développeurs pour différents problèmes, ce qui vous permet de développer plus facilement votre logiciel. Si vous rencontrez des problèmes, vous pouvez signaler des problèmes ou apporter une contribution, et lorsque le problème est résolu, vous pouvez utiliser Yarn pour tout garder à jour.

Le code est partagé via quelque chose appelé package (parfois appelé module). Un package contient tout le code partagé ainsi qu'un fichier package.json qui décrit le package.

plus ici

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

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

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?

webpack-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.

Où utiliseriez-vous browserify? Ne pouvons-nous pas faire de même avec les importations de nœuds / ES6?

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.

Quand utiliseriez-vous gulp / grunt sur npm + plugins?

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 :

var gulp        = require('gulp'),
  minifyCSS     = require('gulp-minify-css'),
  sass          = require('gulp-sass'),
  browserify    = require('gulp-browserify'),
  uglify        = require('gulp-uglify'),
  rename        = require('gulp-rename'),
  jshint        = require('gulp-jshint'),
  jshintStyle   = require('jshint-stylish'),
  replace       = require('gulp-replace'),
  notify        = require('gulp-notify'),

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.

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.

Webpackest un bundler. Comme Browserfyil regarde dans la base de code pour les requêtes de module ( requireou import) et les résout récursivement. De plus, vous pouvez configurer Webpackpour résoudre non seulement les modules de type JavaScript, mais CSS, images, HTML, littéralement tout. Ce qui me passionne particulièrement Webpack, 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' RequireJSun peut aller avec natif ES2016 module system, mais chargé avec System.js( https://github.com/systemjs/systemjs )

En outre, je voudrais souligner qu'il npmest souvent utilisé comme outil d'automatisation comme gruntou gulp. 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. npmconnaît ses packages, vous appelez donc l'un des packages installés localement par son nom, comme:

{
  "scripts": {
    "start": "npm http-server"
  },
  "devDependencies": {
    "http-server": "^0.10.0"
  }
}

En fait, vous n'avez généralement pas besoin de plug-in si le package prend en charge CLI.