NPM vs Bower vs Browserify vs Gulp vs Grunt vs Webpack

J’essaie de résumer mes connaissances sur les gestionnaires de packages JavaScript, les bundlers 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 ne font que télécharger les dépendances et ne savent pas comment construire des projets eux-mêmes. Ce qu’ils savent, c’est appeler webpack / webpack / grunt après avoir récupéré toutes les dépendances.
  • bower est comme npm , mais construit des arbres de dépendances aplatis (contrairement à npm qui le fait récursivement). Ce qui signifie que npm récupère les dépendances pour chaque dépendance (peut être récupérée plusieurs fois), alors que bower attend que vous incluiez manuellement les sous-dépendances. Parfois, bower et npm sont utilisés ensemble pour le front-end et le back-end respectivement (puisque chaque mégaoctet peut avoir une importance sur le front-end).
  • grunt et gulp sont des coureurs de tâches pour automatiser tout ce qui peut être automatisé (c.-à-d. comstackr CSS / Sass, optimiser les images, en faire un paquet et le minimiser / le transposer).
  • grunt vs gulp (est comme gradle vs gradle 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 des stream de nœuds, 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 runner tâche avec le rechargement à chaud des modifications qui vous permet d’oublier tous les observateurs JS / CSS.
  • npm plugins npm / bower + peuvent remplacer les runners de tâche. Leurs capacités se croisent souvent, il y a donc différentes implications si vous devez utiliser gulp / grunt sur npm + plugins. Mais les runners de tâches sont nettement mieux adaptés aux tâches complexes (par exemple, sur chaque build, créez un bundle, passez de ES6 à ES5, exécutez-le sur tous les émulateurs de navigateurs, effectuez des captures d’écran et déployez-les via ftp).
  • browserify permet de conditionner des modules de nœuds pour les navigateurs. browserify vs le require node est en réalité AMD vs CommonJS .

Des questions:

  1. Qu’est-ce que webpack & webpack-dev-server ? La documentation officielle dit que c’est un paquet 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 la même chose avec les importations de nœuds / ES6?
  3. Quand utiliseriez-vous gulp / grunt sur npm + plugins?
  4. Veuillez fournir des exemples lorsque vous devez utiliser une combinaison

Webpack et Browserify

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

Par exemple, supposons que vous ayez écrit 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 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. Exécuter un tel script ne ferait que lancer des erreurs. Ces outils comme Webpack et Browserify résolvent ces problèmes en traduisant ce code dans un formulaire que le navigateur est capable d’exécuter . De plus, ils permettent d’appliquer une grande variété d’optimisations à ces ensembles.

Cependant, Webpack et Browserify diffèrent à bien des égards, Webpack offre de nombreux outils par défaut (par exemple, le fractionnement de code), tandis que Browserify peut le faire uniquement après le téléchargement de plug-ins, mais l’ utilisation des deux conduit à des résultats très similaires . Cela dépend des préférences personnelles (Webpack est plus tendance). Btw, Webpack n’est pas un runner de tâche, il est juste un processeur de vos fichiers (il les traite par des chargeurs et des plugins) et peut être exécuté (entre autres) par un exécuteur de tâches.


Serveur Webpack Dev

Webpack Dev Server fournit une solution similaire à Browsersync – un serveur de développement où vous pouvez déployer rapidement votre application lorsque vous y travaillez, et vérifier immédiatement vos progrès de développement avec le serveur de développement qui actualise automatiquement le navigateur sur les modifications de code sans recharger avec ce qu’on appelle le remplacement de module à chaud.


Task runners vs scripts NPM

J’ai utilisé Gulp pour sa concision et son écriture facile, 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 en utilisant des scripts NPM pour exécuter des outils tiers via leur API. Choisir entre les scripts Gulp, Grunt ou NPM 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 peu familiarisées avec JS, il s’agit d’un autre outil à demander 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 de scripts (proprement JS) qui exécutent ces outils tiers (par exemple, script de noeud configurant et exécutant rimraf à des fins de nettoyage) pourrait s’avérer plus difficile. Mais dans la majorité des cas, ces trois facteurs 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 de React , qui vous 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 . Vous y rencontrerez principalement des commandes telles que les babel-node tools/run start . Babel-node est un outil CLI (non destiné à une utilisation en production), qui comstack dans un premier temps les tools/run fichier ES6 tools/run (fichier run.js situé dans les outils ) – essentiellement un utilitaire runner. Ce runner prend une fonction comme argument et l’exécute, dans ce cas c’est start – un autre utilitaire (start.js) chargé de regrouper les fichiers source (client et serveur) et de démarrer l’application et le serveur de développement (le serveur dev sera probablement Webpack Dev Server ou Browsersync).

Plus précisément, start.js crée à la fois des bundles côté client et serveur, lance express server et après un démarrage réussi inits Browser-sync, qui au moment de l’écriture ressemblait à ceci (référez-vous à la réaction du projet initial 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 : http: // localhost: 3000 , et Browsersync démarre un serveur écoutant sur http: // localhost: 3001 , où les ressources générées sont servies. avec détection automatique des changements et remplacement du module à chaud. Comme vous pouvez le constater, il existe d’autres files propriétés de configuration avec des fichiers individuels ou des modèles. Browser-sync recherche les modifications et recharge le navigateur si certains se produisent, mais comme le dit le commentaire, Webpack surveille lui-même les sources js avec HMR. coopérer là-bas.

Maintenant, je n’ai aucun exemple équivalent d’une telle configuration Grunt ou Gulp, mais avec Gulp (et un peu de la même façon 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 sensiblement les mêmes choses que dans le kit de démarrage, cette fois avec un gestionnaire de tâches, ce 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 plus vous avez de dépendances, plus vous pouvez vous tromper. Et c’est la raison pour laquelle j’aime me débarrasser de ces outils.

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 cette excellente écriture 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 très complet de l’équipe Grab sur la manière d’aborder le développement frontal en 2017. Vous pouvez le vérifier ci-dessous.

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


Je me suis aussi penché sur cette question depuis un certain temps, car il existe de nombreux outils et chacun de nous profite d’un aspect différent. La communauté est divisée entre des outils tels que Browserify, Webpack, jspm, Grunt and Gulp . Vous pourriez aussi entendre parler de Yeoman or Slush . Ce n’est pas vraiment un problème, c’est simplement déroutant pour tout le monde qui essaie de comprendre une voie claire.

En tout cas, je voudrais consortingbuer quelque chose.

1. Gestionnaire de paquets

Les gestionnaires de packages simplifient l’installation et la mise à jour des dépendances de projet, à savoir des bibliothèques telles que: jQuery, Bootstrap , etc. – tout ce qui est utilisé sur votre site et que vous n’avez pas écrit.

Parcourir tous les sites Web de la bibliothèque, télécharger et décompresser les archives, copier les 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écuteriez npm install dans la ligne de commande … puis BANG, vos paquets 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 et principales.

  • Bower : pour la gestion des packages frontaux, le concept est identique avec 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 fait un arbre de dépendances nested tandis que Bower requirejs un arbre de dépendances plat comme ci-dessous.

Citer de Quelle est la différence entre Bower et npm?

MNP

 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 la npm 3 Duplication and Deduplication , ouvrez la doc pour plus de détails.

  • Yarn : Un nouveau gestionnaire de paquets pour JavaScript publié récemment par Facebook 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 qui facilite offline package installs .

  • jspm : est un gestionnaire de paquets pour le chargeur de modules universel SystemJS , construit sur le chargeur de modules ES6 dynamic. Ce n’est pas un gestionnaire de paquets entièrement nouveau avec son propre ensemble de règles, mais il fonctionne plutôt au-dessus des sources de paquets existantes. Hors de la boîte, il fonctionne avec GitHub et npm . Comme la plupart des paquets basés sur Bower sont basés sur GitHub , nous pouvons également installer ces paquets en utilisant jspm . Il possède un registre qui répertorie la plupart des packages frontaux couramment utilisés pour une installation plus facile.

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


2. Chargeur / regroupement de modules

La plupart des projets, quelle que soit leur taille, verront leur code divisé en plusieurs fichiers. Vous pouvez simplement inclure chaque fichier avec une individuelle, cependant, établit une nouvelle connexion http, et pour les petits fichiers - ce qui est un objective de modularité - le temps de configuration de la connexion peut être beaucoup plus long que le transfert. les 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 résolu en concaténant un groupe de modules simples en un seul fichier et en le minifiant.

Par exemple

  Wagon   
  • La performance se fait au désortingment de la flexibilité cependant. Si vos modules sont interdépendants, ce manque de flexibilité peut être un obstacle.

Par exemple

  Skateboard            

Les ordinateurs peuvent le faire mieux que vous ne pouvez, et c'est pourquoi vous devez utiliser un outil pour regrouper automatiquement tout dans un seul fichier.

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

  • RequireJS : est un chargeur de fichiers et de modules JavaScript . 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 myModule.js 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 .

  

En savoir plus sur CommonJS et AMD pour mieux comprendre. Relation entre CommonJS, AMD et RequireJS?

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

Commencez avec une machine de construction sur laquelle node & npm est installé, et 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, émettez la commande à regrouper:

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

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

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 : est un chargeur de module capable d'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 ES6 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 transposer le code ES6 (avec Babel ou Traceur ) ou d'autres langages tels que TypeScript et CoffeeScript utilisant des plugins.

Vous voulez savoir ce qu'est le node module et 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 jspm et SystemJS ?

L'un des principaux objectives de la modularité d' ES6 est de simplifier l'installation et l'utilisation de n'importe quelle bibliothèque Javascript depuis Internet ( Github , npm , etc.). Seules 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érences externes 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, lorsque jspm init , il y aura un fichier nommé config.js à cette fin.

  2. Pour que ces scripts system.js exécutés, nous devons charger system.js et config.js sur la page HTML. Après cela, nous chargerons le fichier SystemJS utilisant le chargeur de module SystemJS .

index.html

    

Noté: Vous pouvez également utiliser npm avec Webpack car Angular 2 l'a appliqué. Depuis que jspm été développé pour s'intégrer à SystemJS et qu'il fonctionne par-dessus les sources npm existantes, votre réponse dépend de vous.


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 devons-nous les utiliser: En un mot: automatisation . Le moins de travail que vous avez à faire lorsque vous effectuez des tâches répétitives telles que la minification, la compilation, les tests unitaires, le linting qui nous ont coûté beaucoup de temps avec la ligne de commande ou même manuellement.

  • Grunt : Vous pouvez créer une automatisation pour votre environnement de développement afin de pré-traiter les codes ou créer des scripts de génération 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 plug-in, qui sont simplement exécutées les unes après les autres, de manière ssortingctement 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 comme Grunt mais au lieu de configurations, vous pouvez écrire du JavaScript avec des stream comme c'est une application de noeud. Préférez 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 prévoyez de créer un prototype avec HTML et SCSS, puis, au lieu de créer manuellement un dossier tel que scss, css, img, les fonts. Vous pouvez simplement installer yeoman et 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 quand je cherche 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 avez trouvé cela utile.

Vous pouvez trouver des comparaisons techniques sur npmcompare

Comparer browserify vs grunt vs gulp vs webpack

Comme vous pouvez le constater, 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 20K écanvass 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

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) bundlers de modules

webpack et browserify comme les plus populaires, fonctionnent comme des runners de tâche mais avec plus de flexibilité, il regroupera tout comme votre paramètre, de sorte que vous pouvez pointer vers le résultat comme bundle.js par exemple dans un seul fichier comprenant le CSS et Javascript, pour plus de détails sur chacun, regardez les détails ci-dessous:

webpack

webpack est un module pour les applications JavaScript modernes. Lorsque webpack traite votre application, elle crée récursivement un graphe de dépendance qui inclut tous les modules dont votre application a besoin, puis empaquette 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 quatre concepts de base: entrée, sortie, chargeurs et plug-ins.

Ce document est destiné à donner une vue d’ensemble 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

navigate

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, exportant des méthodes et des propriétés externes à l’aide des variables module.exports et exports. Nous pouvons même exiger d’autres modules utilisant la fonction require, et si nous omettons le chemin relatif, cela se résoudra au module dans le répertoire node_modules.

plus ici


2) les coureurs de tâches

gulp and grunt sont des coureurs de tâches, essentiellement ce qu’ils font, en créant des tâches et en les exécutant quand vous le voulez, par exemple vous installez un plugin pour minimiser votre CSS puis l’exécutez chaque fois pour minifier.

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 programme d’exécution basé sur Node.js et Node Package Manager (npm), utilisé pour automatiser les tâches fastidieuses 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, une approche basée sur le code sur la configuration pour définir ses tâches et s’appuie sur ses petits plugins à un seul but pour les exécuter. L’écosystème gulp dispose de plus de 1000 plugins disponibles au choix.

plus ici

grognement

Grunt est un gestionnaire de tâches JavaScript, un outil utilisé pour exécuter 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 (Gruntfile) . Grunt a été créé par Ben Alman et est écrit en Node.js. Il est dissortingbué via npm. Actuellement, l’écosystème Grunt compte plus de cinq mille plugins.

plus ici


3) Gestionnaires de paquets

les gestionnaires de paquets, ce qu’ils font est de gérer les plugins dont vous avez besoin dans votre application et de les installer avec github etc. en utilisant package.json, très pratique pour mettre à jour vos modules, les installer et partager votre application

npm

npm est un gestionnaire de paquets pour le langage de programmation JavaScript. C’est le gestionnaire de paquets 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 firebase database en ligne de packages publics, appelée registre npm. Le registre est accessible via le client et les packages disponibles peuvent être parcourus et recherchés via le site Web npm.

plus ici

tonnelle

Bower peut gérer des composants contenant du code HTML, CSS, JavaScript, des fonts ou même des fichiers image. Bower ne concatène ni ne minimise le code ni ne fait autre chose – 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 paquets de tous les côtés, en prenant soin de rechercher, de trouver, de télécharger et de sauvegarder tout ce que vous recherchez. Bower garde trace de ces paquets 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 avant, pour réinstaller les modules, il vérifie le dossier node_modules pour vérifier l’existence du module, semble également que l’installation des modules prend moins de temps:

fil

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. Le fil 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 pour résoudre différents problèmes, facilitant ainsi le développement de vos logiciels. Si vous rencontrez des problèmes, vous pouvez signaler des problèmes ou consortingbuer en retour, et lorsque le problème est résolu, vous pouvez utiliser Yarn pour le garder à jour.

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

plus ici


Une petite note à 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

Qu’est-ce que webpack & webpack-dev-server? La documentation officielle dit que c’est un paquet 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 un retour immédiat sur ce qu’ils font. Il ne doit être utilisé que pendant le développement.

Ce projet s’inspire fortement de l’outil de test unitaire nof5 .

Webpack, comme son nom l’indique, créera un âge SINGLE pack pour le Web . Le paquet sera minimisé et combiné dans un seul fichier (nous vivons toujours dans l’âge HTTP 1.1). Webpack fait la magie de combiner les ressources (JavaScript, CSS, images) et de les injecter comme ceci: .

Il peut également être appelé module bundler car il doit comprendre les dépendances des modules et comment les récupérer 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 sur les mêmes tâches où vous utiliseriez Webpack . – Webpack est plus compact, cependant.

Notez que les fonctionnalités de chargeur de module ES6 dans Webpack2 utilisent System.import , ce que pas un seul navigateur ne prend en charge en mode natif.

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 et vous pouvez éliminer les paquets supplémentaires comme ceux-ci 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é. Donc, là: https://yarnpkg.com/

Après tout, il peut récupérer les dépendances npm et bower et possède d’autres fonctionnalités appréciées.

StackShare fournit un ou plusieurs outils côte à côte en même temps.

Ici, c’est pour npm vs Bower vs Browserify et pour Gulp vs Webpack vs Grunt

Sur ces pages de comparaison, vous pouvez trouver les éléments suivants:

  • nombre de votes reçus par la communauté StackShare
  • quelles entresockets les utilisent dans leur stack technologique
  • niveau d’intérêt pour chaque temps
  • pros pour chaque outil

Webpack est un bundler. Comme Browserfy il recherche les demandes de module ( require ou import ) dans la base de code 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 aussi les CSS, les images, le HTML, littéralement tout. Ce qui me rend particulièrement Webpack par Webpack , vous pouvez combiner des modules compilés et chargés de manière dynamic dans la même application. On obtient ainsi un véritable gain de performances, notamment sur HTTP / 1.x. Comment exactement vous le faites, j’ai décrit avec des exemples ici http://dsheiko.com/weblog/state-of-javascript-modules-2017/ Comme alternative à Bundler, on peut penser à Rollup.js ( https: // rollupjs. org/ ), which optimizes the code during compilation, but ssortingpping all the found unused chunks.

For AMD , instead of RequireJS one can go with native ES2016 module system , but loaded with System.js ( https://github.com/systemjs/systemjs )

Besides, I would point that npm is often used as an automating tool like grunt or gulp . Check out https://docs.npmjs.com/misc/scripts . I personally go now with npm scripts only avoiding other automation tools, though in past I was very much into grunt . With other tools you have to rely on countless plugins for packages, that often are not good written and not being actively maintained. npm knows its packages, so you call to any of locally installed packages by name like:

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

Actually you as a rule do not need any plugin if the package supports CLI.