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

Question

J'essaie de résumer mes connaissances sur les gestionnaires de paquets, les regroupeurs et les exécutants de tâches JavaScript les plus populaires. Veuillez me corriger si je me trompe :

• npm & bower sont des gestionnaires de paquets. Ils se contentent de télécharger les dépendances et ne savent pas comment construire des projets par eux-mêmes. Ce qu'ils savent, c'est qu'il faut appeler webpack / gulp / grunt après avoir récupéré toutes les dépendances.
• bower c'est comme npm mais construit un arbre de dépendances aplati (contrairement à npm qui le fait de manière récursive). Signification npm récupère les dépendances pour chaque dépendance (peut récupérer la même chose plusieurs fois), alors que bower vous demande d'inclure manuellement les sous-dépendances. Parfois, bower y npm 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 y gulp sont des exécutants de tâches pour automatiser tout ce qui peut l'être (c'est-à-dire compiler CSS/Sass, optimiser les images, faire un paquet et le minifier/transpiler).
• grunt vs. gulp (c'est comme maven vs. 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 construire des chaînes de tuyaux (sans rouvrir le même fichier) et le rend plus rapide.
• webpack ( webpack-dev-server ) - pour moi, il s'agit d'un gestionnaire de tâches avec rechargement à chaud des modifications, ce qui permet d'oublier tous les observateurs JS/CSS.
• npm / bower + les plugins peuvent remplacer les task runners. Leurs capacités se recoupent souvent, ce qui entraîne des implications différentes si vous devez utiliser gulp / grunt sur npm + plugins. Mais les task runners sont définitivement meilleurs pour les tâches complexes (par exemple : "à chaque build, créer un bundle, transpiler de ES6 à ES5, l'exécuter sur tous les émulateurs de navigateurs, faire des captures d'écran et déployer sur dropbox via ftp").
• browserify permet d'empaqueter des modules de nœuds pour les navigateurs. browserify vs node 's require est en fait AMD et CommonJS .

Questions :

1. Qu'est-ce que webpack & webpack-dev-server ? La documentation officielle dit que c'est un module bundler mais pour moi c'est juste un task runner. Quelle est la différence ?
2. Où utiliseriez-vous browserify ? Ne peut-on pas faire la même chose avec les importations node/ES6 ?
3. Quand utiliseriez-vous gulp / grunt sur npm + plugins ?
4. Veuillez fournir des exemples de cas où vous devez utiliser une combinaison

Answer 1

Webpack et Browserify

Webpack et Browserify font à peu près le même travail, à savoir traiter votre code pour qu'il soit utilisé dans un environnement cible (principalement le navigateur, bien que vous puissiez cibler d'autres environnements comme Node). Le résultat de ce traitement est un ou plusieurs paquets - assemblé des scripts adaptés à l'environnement ciblé.

Par exemple, disons que vous avez écrit du code ES6 divisé en modules et que vous voulez pouvoir l'exécuter dans un navigateur. Si ces modules sont des modules Node, le navigateur ne les comprendra pas puisqu'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 expérimentales du langage (propositions ES suivantes) que les navigateurs ne mettent pas encore en œuvre, de sorte que l'exécution d'un tel script ne ferait qu'entraîner des erreurs. Des outils comme Webpack et Browserify résolvent ces problèmes en la traduction de ce code en une forme qu'un navigateur est capable d'exécuter . De plus, ils permettent d'appliquer une grande variété d'optimisations sur ces paquets.

Cependant, Webpack et Browserify diffèrent à bien des égards. Webpack offre de nombreux outils par défaut (par exemple, le fractionnement du 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 . C'est une question de préférence personnelle (Webpack est plus tendance). Entre-temps, Webpack n'est pas un exécuteur 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 exécuteur de tâches.

---

Serveur de développement Webpack

Le serveur de développement Webpack offre 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 la progression de votre développement immédiatement, avec le serveur de développement rafraîchissant automatiquement le navigateur sur les changements de code ou même propageant le code modifié au navigateur sans rechargement avec ce qu'on appelle le remplacement de module à chaud.

---

Exécutants de tâches vs. scripts de NPM

J'ai utilisé Gulp pour sa concision et sa facilité d'écriture des tâches, mais j'ai découvert par la suite que je n'ai pas du tout besoin de Gulp ni de Grunt. Tout ce dont j'ai eu besoin aurait pu être fait en utilisant NPM scripts pour exécuter des outils tiers via leur API. Le choix entre Gulp, Grunt ou NPM scripts dépend des goûts 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 qui ne sont pas familières avec JS, c'est encore un autre outil à exiger et à apprendre et je préfère personnellement réduire mes dépendances et rendre les choses simples. D'un autre côté, remplacer ces tâches par la combinaison de NPM scripts et (probablement JS) scripts qui exécutent ces outils tiers (par exemple, Node scripts configurant et exécutant rimraf à des fins de nettoyage) pourrait être plus difficile. Mais dans la majorité des cas, ces trois-là sont égaux en termes de résultats.

---

Exemples

Quant aux exemples, je vous suggère de jeter un coup d'œil à ceci Projet de démarrage React qui vous montre une belle combinaison de NPM et de scripts JS couvrant l'ensemble du processus de construction et de déploiement. Vous pouvez trouver ces scripts NPM en package.json dans le dossier Root, dans une propriété nommée scripts . Vous y trouverez principalement des commandes telles que babel-node tools/run start . Babel-node est un outil CLI (non destiné à une utilisation en production), qui compile d'abord le fichier ES6. tools/run (fichier run.js situé dans outils ) - en fait, un utilitaire pour les coureurs. Ce runner prend une fonction comme argument et l'exécute, qui dans ce cas est start - une autre utilité ( start.js ) responsable de l'empaquetage des fichiers sources (client et serveur) et du démarrage de l'application et du serveur de développement (le serveur de développement sera probablement soit Webpack Dev Server, soit Browsersync).

En parlant plus précisément, start.js crée les bundles côté client et côté serveur, démarre un serveur express et, après un lancement réussi, initialise Browser-sync, qui, au moment de la rédaction, ressemblait à ceci (veuillez vous référer à projet de démarrage react 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 veulent utiliser comme proxy, qui peut être http://localhost:3000 et Browsersync démarre un serveur écoutant sur http://localhost:3001 où les actifs générés bénéficient de la détection automatique des changements et du remplacement à chaud des modules. Comme vous pouvez le constater, il existe une autre propriété de configuration files avec des fichiers individuels ou des modèles Browser-sync surveille les changements et recharge le navigateur si certains se produisent, mais comme le commentaire le dit, Webpack se charge de surveiller les sources js par lui-même avec HMR, donc ils coopèrent là.

Maintenant, je n'ai pas d'exemple équivalent d'une telle configuration de Grunt ou Gulp, mais avec Gulp (et de manière un peu similaire avec Grunt), vous écrivez des tâches individuelles dans gulpfile.js, comme suit

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 les mêmes choses que dans le starter-kit, mais cette fois avec le task runner, qui résout certains problèmes pour vous, mais présente ses propres problèmes et certaines difficultés pendant l'apprentissage de l'utilisation, et comme je l'ai dit, plus vous avez de dépendances, plus il peut y avoir de problèmes. Et c'est la raison pour laquelle j'aime me débarrasser de tels outils.

Answer 2

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 de juin 2018

Apprendre le JavaScript moderne est difficile si vous n'êtes pas là depuis le début. Si vous êtes le nouveau venu, n'oubliez pas de consulter cet excellent écrit pour avoir un meilleur aperçu.

https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70

Mise à jour de juillet 2017

Récemment, j'ai trouvé un guide complet de l'équipe Grab sur la façon d'aborder le développement front-end en 2017. Vous pouvez le consulter comme ci-dessous.

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

---

Je l'ai également cherché pendant un certain temps, car il existe de nombreux outils et chacun d'entre eux nous apporte un avantage différent. La communauté est divisée entre des outils comme Browserify, Webpack, jspm, Grunt and Gulp . Vous pourriez également entendre parler de Yeoman or Slush . Ce n'est pas un problème, c'est juste une source de confusion pour tous ceux qui essaient de comprendre une voie claire à suivre.

Quoi qu'il en soit, j'aimerais apporter ma contribution.

Table des matières

• Table des matières
• 1. Gestionnaire de paquets
  • NPM
  • Bower
  • Différence entre Bower y NPM
  • Fils
  • jspm
• 2. Chargeur de modules / Regroupement
  • RequireJS
  • Browserify
  • Webpack
  • SystemJS
• 3. Coureur de tâches
  • Grunt
  • Gulp
• 4. Outils d'échafaudage
  • Slush et Yeoman

---

1. Gestionnaire de paquets

Les gestionnaires de paquets simplifient l'installation et la mise à jour des dépendances du 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 des bibliothèques, télécharger et décompacter les archives, copier les fichiers dans les projets - tout cela est remplacé par quelques commandes dans le terminal.

NPM

Il représente : 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écuter npm install dans la ligne de commande... puis BANG, vos paquets sont téléchargés et prêts à être utilisés. Il pourrait être utilisé à la fois pour front-end y back-end bibliothèques.

Bower

Pour la gestion frontale des paquets, le concept est le même avec NPM. Toutes vos bibliothèques sont stockées dans un fichier nommé bower.json et ensuite exécuter bower install dans la ligne de commande.

Bower est recommandé à son utilisateur pour migrer vers npm ou yarn . Veuillez faire attention

Différence entre Bower y NPM

La plus grande différence entre Bower y NPM est que NPM fait de l'imbrication tandis que Bower exige un arbre de dépendance plat comme ci-dessous.

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

Fils

Un nouveau gestionnaire de paquets pour JavaScript publié sur par Facebook récemment avec quelques avantages supplémentaires par rapport à NPM . Et avec le fil, vous pouvez toujours utiliser les deux NPM y Bower pour récupérer le paquet. Si vous avez déjà installé un paquet auparavant, yarn crée une copie en cache qui facilite offline package installs .

jspm

JSPM est un gestionnaire de paquets pour le SystemJS chargeur de modules universel, construit sur la base de l'architecture dynamique de l'entreprise. ES6 chargeur de module. Il ne s'agit pas d'un gestionnaire de paquets entièrement nouveau avec son propre ensemble de règles, mais il fonctionne au-dessus des sources de paquets existantes. En l'état, il fonctionne avec GitHub y npm . Comme la plupart des Bower sont basés sur GitHub nous pouvons installer ces paquets en utilisant jspm également. Il dispose d'un registre qui répertorie la plupart des paquets frontaux couramment utilisés pour faciliter l'installation.

Voir la différence entre Bower y jspm : Gestionnaire de paquets : Bower et jspm

---

2. Chargeur de modules / Regroupement

Le code de la plupart des projets, quelle que soit leur ampleur, est réparti entre plusieurs fichiers. Vous pouvez simplement inclure chaque fichier dans un fichier individuel <script> cependant, <script> établit une nouvelle connexion HTTP, et pour les petits fichiers - ce qui est un objectif de la modularité - le temps d'établissement de la connexion peut prendre beaucoup plus de temps que le transfert des données. Pendant que les scripts se téléchargent, 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 réduisant.

Par exemple

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

• Les performances se font toutefois au détriment de la flexibilité. Si vos modules sont interdépendants, ce manque de flexibilité peut être rédhibitoire.

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, et c'est pourquoi vous devriez utiliser un outil pour regrouper automatiquement tout dans un seul fichier.

Puis nous avons entendu parler de RequireJS , Browserify , Webpack y SystemJS

RequireJS

Il s'agit d'un JavaScript et le chargeur de modules. Il est optimisé pour une utilisation dans le navigateur, mais il peut être utilisé dans d'autres environnements JavaScript, tels que Node .

Par exemple monModule.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,
  };
});

Sur main.js nous pouvons importer myModule.js comme une dépendance et l'utiliser.

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

Et puis dans notre HTML on peut se référer à l'utilisation avec RequireJS .

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

Plus d'informations sur CommonJS y AMD pour comprendre facilement. Relation entre CommonJS, AMD et RequireJS ?

Browserify

Établi pour permettre l'utilisation de CommonJS modules formatés dans le navigateur. Par conséquent, Browserify n'est pas tant un chargeur de modules qu'un regroupeur de modules : Browserify est entièrement un outil de construction, produisant un paquet de code qui peut ensuite être chargé côté client.

Commencez par une machine de construction sur laquelle node et npm sont installés, et récupérez le paquet :

npm install -g –save-dev browserify

Écrivez vos modules en CommonJS format

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

Et quand vous êtes satisfaits, donnez la commande au paquet :

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

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

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

Webpack

Il regroupe tous vos actifs statiques, notamment JavaScript les images, les feuilles de style en cascade (CSS), etc., en un seul fichier. Il vous permet également de traiter les fichiers à l'aide de différents types de chargeurs. Vous pouvez écrire votre JavaScript con CommonJS o AMD la syntaxe des modules. Il s'attaque au problème de la construction d'une manière fondamentalement plus intégrée et opinionnée. Dans Browserify vous utilisez Gulp/Grunt et une longue liste de transformations et de plugins pour faire le travail. Webpack offre suffisamment de puissance pour que vous n'ayez pas besoin d'un système d'alarme. Grunt o Gulp du tout.

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

npm install -g –save-dev webpack

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

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

SystemJS

Il s'agit d'un chargeur de modules qui peut importer des modules au moment de l'exécution dans n'importe lequel des formats populaires utilisé aujourd'hui ( CommonJS, UMD, AMD, ES6 ). Il est construit au-dessus de la 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 o Traceur ) ou d'autres langues telles que TypeScript y CoffeeScript en utilisant des plugins.

Vous voulez savoir ce qu'est le node module et pourquoi il n'est pas bien adapté à l'in-browser.

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 jspm y SystemJS ?

L'un des principaux objectifs de ES6 la modularité consiste à rendre les choses très simples d'installer et d'utiliser n'importe quelle bibliothèque Javascript de n'importe où 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

Ainsi, avec jspm vous pouvez le faire.

1. Installer la bibliothèque avec une commande : jspm install jquery
2. Importez la bibliothèque avec une seule ligne de code, sans avoir besoin de référence externe dans votre fichier HTML.

display.js

var $ = require('jquery');

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

3. Ensuite, vous configurez ces choses dans System.config({ ... }) avant d'importer votre module. Normalement, lorsque vous exécutez jspm init il y aura un fichier nommé config.js à cette fin.

4. Pour faire fonctionner ces scripts, nous devons charger system.js y config.js sur la page HTML. Après cela, nous allons charger le fichier display.js en utilisant le site SystemJS chargeur 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 utiliser npm con Webpack comme Angular 2 l'a appliqué. Depuis jspm a été développé pour s'intégrer à SystemJS et il fonctionne en plus du système existant npm source, donc votre réponse ne dépend que de vous.

---

3. Coureur de tâches

Les exécuteurs de tâches et les outils de construction sont principalement des outils en ligne de commande. Pourquoi devons-nous les utiliser ? En un mot : automatisation . Moins vous aurez à travailler lors de l'exécution de tâches répétitives telles que minification, compilation, tests unitaires, linting ce qui nous coûtait auparavant beaucoup de temps à faire en ligne de commande ou même manuellement.

Grunt

Vous pouvez créer une automatisation pour votre environnement de développement pour pré-traiter les 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 dans Grunt est un tableau de différentes configurations de plugins, 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 tout comme Grunt mais au lieu de configurations, vous pouvez écrire JavaScript avec des flux comme si c'était une application de nœud. Je préfère ces jours-ci.

Il s'agit d'un Gulp exemple 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://preslav.me/2015/01/06/gulp-vs-grunt-why-one-why-the-other/

---

4. Outils d'échafaudage

Slush et Yeoman

Vous pouvez créer des projets de démarrage avec eux. Par exemple, si vous envisagez de construire un prototype avec HTML et SCSS, au lieu de créer manuellement des dossiers tels que scss, css, img, fonts, etc. Vous pouvez simplement installer yeoman et lancer un simple script. Ensuite, tout est là pour vous.

Trouver plus aquí .

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 au contenu de la question, mais lorsque je recherche ces connaissances sur Google, je vois toujours la question en haut de la page. J'ai donc décidé d'y répondre en résumé. J'espère que vous l'avez trouvé utile.

Si vous aimez cet article, vous pouvez en lire davantage sur mon blog à l'adresse suivante trungk18.com . Merci de votre visite :)

Answer 3

OK, ils ont tous des similitudes, ils font les mêmes choses pour vous de manières différentes et similaires, je les divise en 3 groupes principaux comme ci-dessous :

---

1) Regroupements de modules

webpack et browserify, qui sont les plus populaires, fonctionnent comme des exécutants de tâches, mais avec plus de flexibilité. En outre, ils regroupent tout ce que vous avez défini, de sorte que vous pouvez pointer le résultat comme bundle.js par exemple, dans un seul fichier comprenant le CSS et le Javascript :

webpack

webpack est un regroupeur de modules pour les applications JavaScript modernes. Lorsque webpack traite votre application, il construit de façon récursive une dépendance de dépendance qui inclut tous les modules dont votre application a besoin, puis regroupe tous ces modules dans un petit nombre de bundles - souvent un seul - qui sera qui seront chargés par le navigateur.

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

Le présent document a pour but de donner un aperçu de haut niveau de ces concepts, tout en fournissant des liens vers des cas d'utilisation détaillés spécifiques.

plus aquí

browserify

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

plus aquí

---

2) Les exécutants de tâches

gulp et grunt sont des exécuteurs de tâches, en gros ce qu'ils font, c'est créer des tâches et les exécuter quand vous voulez, par exemple vous installez un plugin pour minifier votre CSS et l'exécutez à chaque fois pour le minifier, plus de détails sur chacun :

gobler

gulp.js est une boîte à outils JavaScript open-source de Fractal Innovations. Fractal Innovations et la communauté open source sur GitHub. dans le développement web frontal. Il s'agit d'un gestionnaire de tâches construit sur Node.js et Node Package Manager (npm), utilisé pour l'automatisation des tâches fastidieuses et répétitives. tâches fastidieuses et répétitives impliquées dans le développement web comme la minification, la concaténation, l'élimination du cache, les tests unitaires, le linting, l'optimisation, etc. gulp utilise une approche de code sur configuration pour pour définir ses tâches et s'appuie sur ses petits plugins à usage unique pour les réaliser. pour les réaliser. L'écosystème gulp compte plus de 1000 plugins de ce type disponibles parmi lesquels on peut choisir.

plus aquí

grognement

Grunt est un exécuteur de tâches JavaScript, un outil utilisé pour exécuter automatiquement des tâches fréquemment utilisées, telles que la minification, la compilation, l'analyse unitaire, etc. automatiquement des tâches fréquemment utilisées telles que la minification, la compilation tests unitaires, linting, etc. Il utilise une interface de ligne de commande pour exécuter 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, il existe plus de cinq mille plugins disponibles dans l'écosystème de écosystème Grunt.

plus aquí

---

3) Gestionnaires de paquets

les gestionnaires de paquets, qui gèrent les plugins dont vous avez besoin dans votre application et les installent 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 paquets pour le langage de programmation JavaScript. Il est le gestionnaire de paquets par défaut pour l'environnement d'exécution JavaScript. Node.js. Il consiste en un client de ligne de commande, également appelé npm, et une base de données en ligne de paquets publics, appelée le registre npm. Le registre registre est accessible via le client, et les paquets disponibles peuvent être disponibles peuvent être parcourus et recherchés via le site web de npm.

plus aquí

bower

Bower peut gérer des composants qui contiennent du HTML, du CSS, du JavaScript, des fontes ou même des fichiers image. Bower ne concatène pas, ne réduit pas le code et ne fait rien d'autre. autre chose - il se contente d'installer les versions correctes des paquets dont vous avez besoin et de leurs dépendances. Pour commencer, Bower récupère et installe des paquets de partout. paquets de partout, se chargeant de rechercher, trouver, télécharger et enregistrer les les éléments que vous recherchez. Bower garde la trace de ces paquets dans un fichier manifeste, bower.json.

plus aquí

et le plus récent gestionnaire de paquets à ne pas manquer, il est jeune et rapide dans un environnement de travail réel comparé à npm que j'utilisais principalement avant, pour la réinstallation des modules, il vérifie deux fois le dossier node_modules pour vérifier l'existence du module, il semble aussi que l'installation des modules prenne moins de temps :

fils

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

Yarn vous permet d'utiliser les solutions d'autres développeurs à différents problèmes. problèmes, ce qui facilite le développement de votre logiciel. Si vous problèmes, vous pouvez signaler les problèmes ou apporter votre contribution, et lorsque le problème est corrigé, vous pouvez utiliser Yarn pour maintenir le tout à jour.

Le code est partagé par le biais d'un paquet (parfois appelé module). module). Un paquet contient tout le code qui est partagé ainsi que ainsi qu'un fichier package.json qui décrit le paquet.

plus aquí

---

Answer 4

Vous pouvez trouver une comparaison technique sur npmcompare

Comparer browserify vs. grunt vs. gulp vs. webpack

Comme vous pouvez le constater, webpack est très bien maintenu avec une nouvelle version 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 je devais choisir l'un plutôt que l'autre, je choisirais Gulp.

Answer 5

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

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