web-dev-qa-db-fra.com

NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack

J'essaie de résumer mes connaissances sur les gestionnaires de paquets JavaScript, les bundles et les coureurs de tâches les plus populaires. Corrigez-moi si j'ai tort, s'il-vous plait:

  • npm & bower sont des gestionnaires de paquets. Ils téléchargent simplement les dépendances et ne savent pas comment construire des projets par eux-mêmes. Ce qu'ils savent, c'est appeler webpack/gulp/grunt après avoir récupéré toutes les dépendances.
  • bower ressemble à npm, mais construit des arbres de dépendances aplaties (contrairement à npm qui le fait de manière récursive). Signification npm récupère les dépendances pour chaque dépendance (peut aller chercher la même chose plusieurs fois), alors que bower s'attend à ce que vous incluiez manuellement des sous-dépendances. Parfois, bower et npm sont utilisés ensemble pour le front-end et le back-end, respectivement (chaque mégaoctet pouvant être important pour le front-end).
  • grunt et gulp sont des exécuteurs de tâches qui automatisent tout ce qui peut être automatisé (compiler CSS/Sass, optimiser les images, créer un paquet et le minimiser/le transpiler).
  • grunt vs. gulp (est comme maven contre gradle ou configuration vs code). Grunt est basé sur la configuration de tâches indépendantes distinctes, chaque tâche ouvre/manipule/ferme le fichier. Gulp nécessite moins de code et est basé sur les flux Node, ce qui lui permet de créer des chaînes de canaux (sans rouvrir le même fichier) et de le rendre plus rapide.
  • webpack (webpack-dev-server) - pour moi, c'est un coureur de tâches avec un rechargement à chaud des modifications qui vous permet d'oublier tous les observateurs JS/CSS.
  • npm/bower + les plugins peuvent remplacer les coureurs de tâches. Leurs compétences se recoupent souvent, de sorte qu'il y a différentes implications si vous devez utiliser gulp/grunt sur npm + plugins. Mais les coureurs de tâches sont définitivement meilleurs pour les tâches complexes (par exemple, "sur chaque build, créer un paquet, transpiler de ES6 à ES5, l'exécuter sur tous les émulateurs de navigateurs, faire des captures d'écran et se déployer dans une boîte de transfert via ftp").
  • browserify permet de conditionner des modules de nœud pour les navigateurs. browserify vs node's require est en réalité AMD vs CommonJS .

Questions:

  1. Qu'est-ce que webpack & webpack-dev-server?] La documentation officielle indique qu'il s'agit d'un bundle de modules, mais pour moi, il ne s'agit que d'un coureur de tâches. Quelle est la différence?
  2. Où utiliseriez-vous browserify? Ne pouvons-nous pas en faire autant avec les importations de nœuds/ES6?
  3. Quand utiliseriez-vous gulp/grunt sur npm + plugins?
  4. Veuillez donner des exemples lorsque vous devez utiliser une combinaison
gruntjsnpmgulpbowerwebpack
1771
VB_

Webpack et Browserify

Webpack et Browserify effectuent à peu près le même travail, qui consiste à traiter votre code pour l’utiliser dans un environnement cible (principalement un navigateur, bien que vous puissiez cibler d’autres environnements. comme Node). Le résultat de ce traitement est un ou plusieurs ensembles - scripts assemblés adaptés à un environnement ciblé.

Par exemple, supposons que vous écriviez un code ES6 divisé en modules et que vous souhaitiez 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 navigateurs plus anciens tels que IE11. De plus, vous avez peut-être utilisé des fonctionnalités de langage expérimental (propositions ES suivantes) que les navigateurs n’implémentent pas encore; l’exécution d’un tel script ne ferait que générer des erreurs. Ces outils, tels que Webpack et Browserify, résolvent ces problèmes en traduisant ce code dans un navigateur de formulaire capable de s’exécuter . En plus de cela, ils permettent d'appliquer une grande variété d'optimisations à ces bundles.

Cependant, Webpack et Browserify diffèrent à bien des égards, Webpack propose par défaut de nombreux outils (par exemple, le fractionnement de code), alors que Browserify peut le faire uniquement après avoir téléchargé des plugins, mais en utilisant les deux entraîne des résultats très similaires . Cela dépend de vos préférences personnelles (Webpack est plus tendance). Btw, Webpack n'est pas un programme d'exécution de tâches, c'est juste un processeur de vos fichiers (il les traite par des chargeurs et des plugins) et il peut être exécuté (entre autres) par un programme d'exécution de tâches.

Webpack Dev Server

Webpack Dev Server fournit une solution similaire à Browsersync - un serveur de développement sur lequel vous pouvez déployer votre application rapidement au fur et à mesure que vous y travaillez, et vérifier immédiatement l'état de votre développement avec le serveur de développement en actualisant automatiquement le navigateur lors de la modification du code ou même en le propageant au navigateur. sans rechargement avec le remplacement dit de module à chaud.

Coureurs de tâches vs scripts NPM

J'utilise Gulp pour sa concision et sa facilité à écrire des tâches, mais j'ai par la suite découvert 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 moins familiarisées avec JS, il s’agit d’un outil supplémentaire à exiger et à apprendre et je préfère personnellement réduire les dépendances et simplifier les choses. D'autre part, remplacer ces tâches par la combinaison de scripts NPM et de scripts (proprement JS) exécutant ces outils tiers (par exemple, Node script 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 d’examiner ce projet de démarrage React , qui montre une belle combinaison de scripts NPM et JS couvrant l’ensemble du processus de construction et de déploiement. Vous pouvez trouver ces scripts NPM dans package.json dans le dossier racine, dans une propriété nommée scripts. Là, vous rencontrerez principalement des commandes telles que babel-node tools/run start. Babel-node est un outil CLI (non destiné à une utilisation en production), qui compile dans un premier temps le fichier ES6 tools/run (fichier run.js situé dans outils ). utilitaire de coureur. Ce runner prend une fonction en tant qu'argument et l'exécute, qui dans ce cas est start - un autre utilitaire (start.js) chargé de regrouper les fichiers source (à la fois client et serveur) et de démarrer l'application et le serveur de développement (le Le serveur dev sera probablement Webpack Dev Server ou Browsersync).

Parlant plus précisément, start.js crée des ensembles côté client et côté serveur, démarre Express Server et, après le démarrage réussi, dans Synchronisation avec le navigateur, qui ressemblait à ceci au moment de la rédaction (se référer à ). 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 sur laquelle ils veulent utiliser un proxy, ce qui pourrait être http: // localhost: 3000 , et Browsersync démarre l'écoute du serveur. http: // localhost: 3001 , où les actifs générés sont servis avec la détection automatique des modifications et le remplacement du module actif. Comme vous pouvez le constater, il existe une autre propriété de configuration files avec des fichiers ou des modèles individuels. Synchronisation par navigateur surveille les modifications et recharge le navigateur si nécessaire, mais comme le dit le commentaire, Webpack se charge de regarder les sources js par lui-même avec HMR, alors ils coopèrent là-bas.

Maintenant, je n'ai pas d'exemple équivalent d'une telle configuration de Grunt ou de Gulp, mais avec Gulp (et un peu de la même manière avec Grunt), vous écrivez 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-ci avec task runner, 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 le dis, le plus vous avez de dépendances, plus vous pouvez vous tromper. Et c’est la raison pour laquelle j’ai envie de me débarrasser de tels outils.

948
Dan Macák

Mise à jour d'octobre 2018

Si vous avez encore des doutes sur Front-end dev, jetez un coup d’œil rapide sur une excellente ressource ici.

https://github.com/kamranahmedse/developer-roadmap

Mise à jour de juin 2018

Il est difficile d’apprendre le JavaScript moderne si vous n’êtes plus là 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-f695e9747b7

Mise à jour juillet 2017

Récemment, j'ai trouvé un guide très complet de l'équipe de Grab sur la façon d'aborder le développement frontal en 2017. Vous pouvez le vérifier ci-dessous.

https://github.com/grab/front-end-guide

Je suis aussi à la recherche de 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 tels que _Browserify, Webpack, jspm, Grunt and Gulp_. Vous pourriez également entendre parler de _Yeoman or Slush_. Ce n’est pas vraiment un problème, c’est une source de confusion pour tout le monde qui essaie de comprendre une voie claire vers l’avenir.

Quoi qu'il en soit, j'aimerais apporter quelque chose.

1. Gestionnaire de paquets

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 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éfinissez vos besoins dans un fichier appelé _package.json_ et exécutez _npm install_ dans la ligne de commande ... puis BANG, vos packages sont téléchargés et prêts à être utilisés. Peut être utilisé à la fois pour les bibliothèques _front-end and back-end_.

  • Bower : pour la gestion des packages front-end, le concept est identique à NPM. Toutes vos bibliothèques sont stockées dans un fichier nommé _bower.json_, puis exécutez _bower install_ dans la ligne de commande.

La plus grande différence entre Bower et NPM est que NPM crée un arbre de dépendance imbriqué, tandis que Bower requiert un arbre de dépendance plat, comme ci-dessous.

Citant 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
_

Bower

_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 des mises à jour sur npm 3 Duplication and Deduplication , veuillez ouvrir le document pour plus de détails.

  • Yarn : Un nouveau gestionnaire de paquets pour JavaScriptpublié par Facebook récemment avec quelques avantages supplémentaires par rapport à NPM. Et avec Yarn, vous pouvez toujours utiliser le registre NPM et Bower pour récupérer le package. Si vous avez déjà installé un package, yarn crée une copie en cache facilitant _offline package installs_.

  • jspm : est un gestionnaire de paquets pour le chargeur de module universel SystemJS, construit sur le chargeur de module dynamique _ES6_. Ce n'est pas un tout nouveau gestionnaire de paquets avec son propre ensemble de règles, mais il fonctionne au-dessus des sources de paquets existantes. Hors de la boîte, cela fonctionne avec GitHub et npm. Comme la plupart des packages basés sur Bower sont basés sur GitHub, nous pouvons également installer ces packages à l'aide de jspm. Son registre répertorie la plupart des packages front-end les plus couramment utilisés pour une installation plus facile.

Voir les différences entre Bower et jspm: Gestionnaire de paquets: Bower vs jspm

2. Module Loader/Bundling

La plupart des projets de toutes tailles auront leur code divisé en plusieurs fichiers. Vous pouvez simplement inclure chaque fichier avec une balise _<script>_ individuelle. Cependant, _<script>_ établit une nouvelle connexion http. considérablement plus long 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 en grande partie résolu en concaténant un groupe de modules simples dans un fichier unique et en le réduisant au minimum.

Par exemple

_<head>
    <title>Wagon</title>
    <script src=“build/wagon-bundle.js”></script>
</head>
_
  • La performance se fait au détriment de la flexibilité. Si vos modules sont interdépendants, ce manque de flexibilité peut constituer un obstacle.

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 le faire mieux que vous, c'est pourquoi vous devez utiliser un outil pour regrouper automatiquement le tout dans un seul fichier.

Ensuite nous avons entendu parler de RequireJS, Browserify, Webpack et SystemJS

  • RequireJS : est un chargeur de fichier et de module JavaScript. Il est optimisé pour une utilisation dans le navigateur, mais il peut être utilisé dans d'autres environnements JavaScript, tels que Node.

E.g: 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 _myModule.js_ en tant 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 CommonJS et AMD pour comprendre facilement. Relation entre CommonJS, AMD et RequireJS?

  • Browserify : permet d'autoriser l'utilisation de modules au format CommonJS dans le navigateur. Par conséquent, Browserify n'est pas autant un chargeur de module qu'un bundle de modules: Browserify est entièrement un outil de compilation, produisant un ensemble de code qui peut ensuite être chargé côté client.

Commencez avec une machine de construction sur laquelle le noeud & npm est installé, puis récupérez le paquet:

_npm install -g –save-dev browserify
_

Ecrivez vos modules au format CommonJS

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

Et quand heureux, lancez la commande pour grouper:

_browserify entry-point.js -o bundle-name.js
_

Browserify trouve 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 JavaScript, images, CSS, etc., dans un seul fichier. Il vous permet également de traiter les fichiers via différents types de chargeurs. Vous pouvez écrire votre syntaxe de modules JavaScript avec CommonJS ou AMD. Il s'attaque au problème de construction de manière fondamentalement plus intégrée et plus réfléchie. Dans Browserify, vous utilisez _Gulp/Grunt_ et une longue liste de transformations et de plug-ins pour effectuer le travail. Webpack offre suffisamment de puissance hors de la boîte pour que vous n’ayez généralement pas besoin de Grunt ou Gulp.

L'utilisation de base est au-delà du 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 courants utilisés aujourd'hui (_CommonJS, UMD, AMD, ES6_). Il est construit sur le chargeur de modules _ES6_ 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 (avec Babel ou Traceur) ou d'autres langages tels que TypeScript et CoffeeScript à l'aide de plugins.

Vous voulez savoir ce qu'est le _node module_ et pourquoi il n'est pas bien adapté au navigateur.

Article plus utile:

Pourquoi jspm et SystemJS?

L'un des principaux objectifs de la modularité _ES6_ est de simplifier l'installation et l'utilisation de toutes les bibliothèques Javascript à partir de n'importe où sur Internet (Github, npm, etc.). Seulement deux choses 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 dans votre fichier HTML.

display.js 

_var $ = require('jquery'); 

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

  1. Ensuite, vous configurez ces éléments dans System.config({ ... }) avant d'importer votre module. Normalement, lors de l'exécution de _jspm init_, il y aura un fichier nommé _config.js_ à cette fin.

  2. Pour que ces scripts soient exécutés, nous devons charger _system.js_ et _config.js_ sur la page HTML. Ensuite, nous chargerons le fichier _display.js_ à l’aide du chargeur de modules SystemJS.

index.html 

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

Remarque: vous pouvez également utiliser npm avec Webpack comme Angular 2 l'a appliqué. Étant donné que jspm a été développé pour s'intégrer à SystemJS et qu'il fonctionne par-dessus la source npm existante, votre réponse vous appartient.

3. Coureur de tâche

Les coureurs 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 seul mot: automation . Moins de travail à effectuer lors de tâches répétitives telles que la minification, la compilation, les tests unitaires, le lintage , qui nous coûtait auparavant beaucoup de temps avec la commande ligne ou même manuellement.

  • Grunt : Vous pouvez créer une automatisation de votre environnement de développement pour pré-traiter les codes ou créer des scripts de construction avec un fichier de configuration. Il semble très difficile de gérer une tâche complexe. Populaire ces dernières années.

Chaque tâche dans Grunt est un tableau de différentes configurations de plug-ins, 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 : Automatisation à la manière de Grunt, mais au lieu de configurations, vous pouvez écrire JavaScript avec des flux comme s'il s'agissait d'une application nodale. Préfère ces jours.

Ceci est un exemple de déclaration de tâche Gulp.

_//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 envisagez de créer un prototype avec HTML et SCSS, puis de créer manuellement un dossier tel que scss, css, img, polices. Vous pouvez simplement installer yeoman et exécuter un script simple. Alors tout ici pour vous.

Trouver 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 au-dessus, de sorte que j'ai décidé d'y répondre en résumé. J'espère que vous l'avez trouvé utile.

639
trungk18

Vous pouvez trouver des comparaisons techniques sur npmcompare

Comparaison entre browserify, grunt, gulp et webpack

Comme vous pouvez le constater, webpack est très bien géré avec une nouvelle version tous les 4 jours. Mais Gulp semble avoir la plus grande communauté de tous (avec plus de 20K stars sur Github) Grunt semble un peu négligé (comparé aux autres)

Donc, si besoin de choisir l’un sur l’autre, j’irais avec Gulp

49
dcohenb

Une petite remarque à propos de npm: npm3 essaie d'installer les dépendances de manière plate

https://docs.npmjs.com/how-npm-works/npm3#npm-v3-dependency-resolution

41
DeadWoroz

Yarn est un gestionnaire de paquets récent qui mérite probablement d'être mentionné. Donc, là: https://yarnpkg.com/

Bien sûr, il peut aller chercher les dépendances npm et bower et possède d’autres fonctionnalités appréciées.

12
Ellone

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 coureur de tâches. Quelle est la différence?

webpack-dev-server est un serveur Web de rechargement en direct que les développeurs de Webpack utilisent pour obtenir un retour immédiat sur leur travail. Il ne devrait être utilisé que pendant le développement.

Ce projet est fortement inspiré par l’outil de test unitaire nof5 .

Webpack comme son nom l’indique, créera un SINGLE pack pour le web . Le paquet sera minimisé et combiné dans un seul fichier (nous vivons toujours dans 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 module 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 la même chose avec les importations de nœuds/ES6?

Vous pouvez utiliser Browserify pour les mêmes tâches que celles que vous utiliseriez Webpack. - Webpack est plus compact, cependant.

Notez que les fonctionnalités du chargeur de module ES6 dans Webpack2 utilisent System.import, qui n'est pris en charge de manière native par aucun navigateur.

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

Vous pouvez oublierGulp, Grunt, Brokoli, Brunch and Bower. Utilisez directement les scripts de ligne de commande npm à la place et vous pouvez éliminer les paquets supplémentaires tels que 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 Gulp et Grunt ​​générateurs de fichiers de configuration 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.

12
prosti

Webpack est un bundle. Comme Browserfy, il recherche dans la base de code les requêtes de modules (require ou import) et les résout de manière récursive. De plus, vous pouvez configurer Webpack pour résoudre non seulement les modules de type JavaScript, mais également les CSS, les images, le HTML, littéralement tout. Ce qui me rend particulièrement enthousiasmé par Webpack, vous pouvez combiner des modules compilés et chargés dynamiquement dans la même application. Ainsi, on obtient une réelle amélioration des performances, notamment via HTTP/1.x. Comment exactement vous le faites-vous, j'ai décrit avec des exemples ici (http://dsheiko.com/weblog/state-of-javascript-modules-2017/ ) Comme alternative à un paquet, on peut penser à Rollup.js _ ( https://rollupjs.org/ ), qui optimise le code lors de la compilation, mais en supprimant tous les fragments inutilisés trouvés.

Pour AMD, au lieu de RequireJS, on peut utiliser le ES2016 module system natif, mais chargé avec le System.js ( https://github.com/systemjs/systemjs )

En outre, je ferais remarquer que npm est souvent utilisé comme un outil d’automatisation tel que grunt ou gulp. Départ https://docs.npmjs.com/misc/scripts . Personnellement, je vais maintenant avec les scripts npm en évitant uniquement les autres outils d’automatisation, même si j’étais très attaché à grunt. Avec d'autres outils, vous devez compter sur d'innombrables plugins pour les paquets, qui souvent ne sont pas bien écrits et ne sont pas maintenus activement. npm connaît ses paquets, vous appelez donc les paquets installés localement par leur nom, par exemple:

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

En fait, vous n’avez en principe besoin d’aucun plugin si le paquet supporte CLI.

9
Dmitry Sheiko