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

Sto cercando di riassumere le mie conoscenze sui più noti gestori di pacchetti JavaScript, bundler e task runner. Per favore correggimi se sbaglio:

  • npm e bower sono gestori di pacchetti. Scaricano solo le dipendenze e non sanno come build progetti da soli. Quello che sanno è chiamare webpack / gulp / grunt dopo aver recuperato tutte le dipendenze.
  • bower è come npm , ma crea alberi di dipendenze appiattite (a differenza di npm che lo fanno in modo ricorsivo). Il significato di npm recupera le dipendenze per ogni dipendenza (può recuperare lo stesso poche volte), mentre per il bower prevede di includere manualmente le dipendenze secondarie. A volte bower e npm vengono usati insieme rispettivamente per front-end e back-end (dato che ogni megabyte potrebbe importare sul front-end).
  • grunt e gulp sono task runner per automatizzare tutto ciò che può essere automatizzato (ad esempio, compilare CSS / Sass, ottimizzare le immagini, creare un bundle e ridurlo / trasformarlo).
  • grunt vs. gulp (è come gradle vs. gradle o configuration vs. code). Grunt si basa sulla configurazione di attività indipendenti separate, ogni attività apre / gestisce / chiude il file. Gulp richiede meno quantità di codice e si basa su flussi di nodes, che gli consentono di build catene di condotte (senza riaprire lo stesso file) e renderlo più veloce.
  • webpack ( webpack-dev-server ) – per me è un task runner con hot ricaricamento delle modifiche che ti permette di dimenticare tutti gli osservatori JS / CSS.
  • npm / bower + plugins possono sostituire i task runner. Le loro abilità spesso si intersecano quindi ci sono diverse implicazioni se è necessario usare gulp / grunt su npm + plugin. Tuttavia, i task runner sono decisamente migliori per compiti complessi (ad esempio “su ogni build crea bundle, trasponi da ES6 a ES5, eseguilo su tutti gli emulatori di browser, crea schermate e distribuisci su dropbox tramite ftp”).
  • browserify consente moduli di moduli di packaging per i browser. browserify contro il node require è in realtà AMD vs CommonJS .

Domande:

  1. Che cos’è webpack e webpack-dev-server ? La documentazione ufficiale dice che è un modulo bundler ma per me è solo un corridore di compiti. Qual è la differenza?
  2. Dove browserify ? Non possiamo fare lo stesso con le importazioni di nodo / ES6?
  3. Quando npm gulp / grunt su npm + plugin?
  4. Si prega di fornire esempi quando è necessario utilizzare una combinazione

Webpack e Browserify

Webpack e Browserify svolgono praticamente lo stesso lavoro, ovvero l’ elaborazione del codice da utilizzare in un ambiente di destinazione (principalmente browser, sebbene sia ansible scegliere come target altri ambienti come Node). Il risultato di tale elaborazione è uno o più pacchetti : script assemblati adatti per l’ambiente di destinazione.

Ad esempio, supponiamo che tu abbia scritto un codice ES6 diviso in moduli e desideri eseguirlo nel browser. Se questi moduli sono moduli nodo, il browser non li capirà poiché esistono solo nell’ambiente nodo. I moduli ES6 inoltre non funzioneranno con i browser più vecchi come IE11. Inoltre potreste aver usato le funzionalità del linguaggio sperimentale (proposte successive di ES) che i browser non implementano ancora, quindi l’esecuzione di tale script causerebbe solo errori. Questi strumenti come Webpack e Browserify risolvono questi problemi traducendo tale codice in un browser che è in grado di eseguire . Inoltre, consentono di applicare un’enorme varietà di ottimizzazioni su questi bundle.

Tuttavia, Webpack e Browserify differiscono in molti modi, per impostazione predefinita Webpack offre molti strumenti (ad esempio la divisione del codice), mentre Browserify può farlo solo dopo aver scaricato i plug-in, ma utilizzando entrambi i lead per risultati molto simili . Si tratta di preferenze personali (Webpack è più alla moda). Btw, Webpack non è un task runner, è solo un processore dei tuoi file (li elabora tramite i cosiddetti caricatori e plug-in) e può essere eseguito (tra l’altro) da un task runner.


Webpack Dev Server

Webpack Dev Server offre una soluzione simile a Browsersync, un server di sviluppo in cui è ansible distribuire rapidamente l’app mentre ci si sta lavorando e verificare immediatamente i progressi di sviluppo con il server di sviluppo aggiornando automaticamente il browser in caso di modifiche al codice o propagando il codice modificato nel browser senza ricaricare con la cosiddetta sostituzione del modulo caldo.


Corridori di attività rispetto agli script NPM

Ho usato Gulp per la sua concisione e la facilità di scrittura, ma in seguito ho scoperto che non ho bisogno né di Gulp né di Grunt. Tutto ciò di cui ho sempre avuto bisogno avrebbe potuto essere fatto usando gli script NPM per eseguire strumenti di terze parti attraverso le loro API. La scelta tra gli script Gulp, Grunt o NPM dipende dal gusto e dall’esperienza della tua squadra.

Mentre le attività in Gulp o Grunt sono facili da leggere anche per le persone che non hanno familiarità con JS, è ancora un altro strumento da richiedere e imparare e personalmente preferisco restringere le mie dipendenze e semplificare le cose. D’altro canto, la sostituzione di queste attività con la combinazione di script NPM e script (probabilmente JS) che eseguono questi strumenti di terze parti (ad esempio la configurazione degli script dei nodes e l’esecuzione di rimraf per la pulizia) potrebbe essere più impegnativa. Ma nella maggior parte dei casi, questi tre sono uguali in termini di risultati.


Esempi

Per quanto riguarda gli esempi, suggerisco di dare un’occhiata a questo progetto di avviamento React , che mostra una buona combinazione di script NPM e JS che coprono l’intero processo di compilazione e distribuzione. È ansible trovare gli script NPM in package.json nella cartella radice, in una proprietà denominata scripts . Lì per la maggior parte incontrerai comandi come gli babel-node tools/run start . Babel-node è uno strumento CLI (non inteso per uso di produzione), che dapprima compila gli tools/run file ES6 tools/run (file run.js che si trova negli strumenti ) – fondamentalmente un’utilità per runner. Questo runner accetta una funzione come argomento e la esegue, che in questo caso è avviata, un’altra utility (start.js) responsabile del raggruppamento dei file di origine (client e server) e dell’avvio del server di applicazioni e di sviluppo (il server di sviluppo sarà probabilmente Webpack Dev Server o Browsersync).

Parlando in modo più preciso, start.js crea sia i bundle lato client che lato server, avvia express server e dopo aver avviato correttamente in-Browser sync, che al momento della stesura sembrava questo (fare riferimento a react starter project per il codice più recente).

 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 parte importante è proxy.target , dove impostano l’indirizzo del server che vogliono utilizzare come proxy, che potrebbe essere http: // localhost: 3000 e Browsersync avvia un server in ascolto su http: // localhost: 3001 , dove vengono servite le risorse generate con rilevamento automatico delle modifiche e sostituzione dei moduli caldi. Come puoi vedere, c’è un altro files proprietà di configurazione con singoli file o pattern Browser-sync guarda per le modifiche e ricarica il browser se si verificano alcuni, ma come dice il commento, Webpack si occupa di guardare le sorgenti js da solo con HMR, quindi collaborare lì.

Ora non ho alcun esempio equivalente di tale configurazione Grunt o Gulp, ma con Gulp (e in qualche modo simile a Grunt) dovresti scrivere singole attività in gulpfile.js come

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

dove dovresti fare praticamente le stesse cose del kit di partenza, questa volta con task runner, che risolve alcuni problemi per te, ma presenta i suoi problemi e alcune difficoltà durante l’apprendimento dell’uso, e come dico, il più dipendenze hai, più può andare storto. E questa è la ragione per cui mi piace sbarazzarmi di questi strumenti.

Aggiornamento giugno 2018

Imparare il JavaScript moderno è difficile se non ci sei mai stato dall’inizio. Se sei il nuovo arrivato, ricorda di controllare questo eccellente scritto per avere una visione migliore.

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

Aggiornamento luglio 2017

Recentemente ho trovato una guida davvero completa del team di Grab su come affrontare lo sviluppo front-end nel 2017. Puoi verificarlo come di seguito.

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


Sono stato anche alla ricerca di questo da un po ‘di tempo poiché ci sono molti strumenti là fuori e ognuno di loro ci avvantaggia in un aspetto diverso. La comunità è divisa tra strumenti come Browserify, Webpack, jspm, Grunt and Gulp . Potresti anche sentire parlare di Yeoman or Slush . Non è davvero un problema, è solo confusione per tutti coloro che cercano di capire un percorso chiaro in avanti.

Ad ogni modo, vorrei contribuire con qualcosa.

1. Gestore pacchetti

I gestori di pacchetti semplificano l’installazione e l’aggiornamento delle dipendenze del progetto, che sono librerie come: jQuery, Bootstrap , ecc. – tutto ciò che viene usato sul tuo sito e non è scritto da te.

Navigando in tutti i siti web della biblioteca, scaricando e decomprimendo gli archivi, copiando i file nei progetti, tutto questo viene sostituito con alcuni comandi nel terminale.

  • NPM sta per: Node JS package manager ti aiuta a gestire tutte le librerie su cui si basa il tuo software. npm install tue esigenze in un file chiamato package.json ed npm install nella riga di comando … poi BANG, i tuoi pacchetti saranno scaricati e pronti per l’uso. Potrebbe essere utilizzato sia per le librerie front-end and back-end .

  • Bower : per la gestione dei pacchetti front-end, il concetto è lo stesso con NPM. Tutte le tue librerie sono memorizzate in un file chiamato bower.json e quindi eseguire bower install nella riga di comando.

La più grande differenza tra Bower e NPM è che NPM fa un albero delle dipendenze annidato mentre Bower richiede un albero di dipendenza piatto come sotto.

Citando da Qual è la differenza tra Bower e 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 

pergolato

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

Ci sono alcuni aggiornamenti su npm 3 Duplication and Deduplication , si prega di aprire il documento per maggiori dettagli.

  • Yarn : Un nuovo gestore di pacchetti per JavaScript pubblicato da Facebook recente con alcuni vantaggi in più rispetto a NPM . E con Yarn, puoi comunque utilizzare sia il registro NPM che Bower per recuperare il pacchetto. Se hai già installato un pacchetto, yarn crea una copia nella cache che facilita le offline package installs .

  • jspm : è un gestore di pacchetti per il SystemJS universale per moduli SystemJS , costruito sopra il caricatore dinamico dei moduli ES6 . Non è un gestore di pacchetti completamente nuovo con un proprio insieme di regole, ma funziona in aggiunta alle sorgenti di pacchetti esistenti. Fuori dalla scatola, funziona con GitHub e npm . Poiché la maggior parte dei pacchetti basati su Bower si basano su GitHub , possiamo installare questi pacchetti usando jspm . Ha un registro che elenca la maggior parte dei pacchetti front-end comunemente usati per facilitare l’installazione.

Guarda la differenza tra Bower e jspm : Gestore pacchetti: Bower vs jspm


2. Caricatore / raggruppamento del modulo

La maggior parte dei progetti di qualsiasi scala avrà il loro codice suddiviso tra un numero di file. Puoi semplicemente includere ogni file con un singolo tag , tuttavia stabilisce una nuova connessione http e, per i file di piccole dimensioni, che è un objective di modularità, il tempo necessario per impostare la connessione può richiedere molto più tempo rispetto al trasferimento i dati. Mentre gli script vengono scaricati, nessun contenuto può essere modificato sulla pagina.

  • Il problema del tempo di download può essere risolto in gran parte concatenando un gruppo di moduli semplici in un singolo file e ministrandolo.

Per esempio

  Wagon   
  • Tuttavia, la prestazione è a scapito della flessibilità. Se i tuoi moduli hanno interdipendenza, questa mancanza di flessibilità potrebbe essere un ostacolo.

Per esempio

  Skateboard            

I computer possono farlo meglio di te, ed è per questo che dovresti usare uno strumento per raggruppare automaticamente tutto in un unico file.

Poi abbiamo sentito di RequireJS , Browserify , Webpack e SystemJS

  • RequireJS : è un file JavaScript e un caricatore di moduli. È ottimizzato per l'uso in-browser, ma può essere utilizzato in altri ambienti JavaScript, come il Node .

Ad esempio: 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 } }); 

In main.js , possiamo importare myModule.js come dipendenza e usarlo.

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

E poi nel nostro HTML , possiamo fare riferimento all'uso con RequireJS .

  

Maggiori informazioni su CommonJS e AMD per comprendere facilmente. Relazione tra CommonJS, AMD e RequireJS?

  • Browserify : impostato per consentire l'uso di moduli formattati CommonJS nel browser. Di conseguenza, Browserify non è tanto un caricatore di moduli quanto un bundle di moduli: Browserify è interamente uno strumento di costruzione, che produce un fascio di codice che può quindi essere caricato sul lato client.

Inizia con una macchina di compilazione che ha installato node & npm e ottieni il pacchetto:

 npm install -g –save-dev browserify 

Scrivi i tuoi moduli in formato CommonJS

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

E quando è felice, invia il comando per raggruppare:

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

Browserify trova ricorsivamente tutte le dipendenze del punto di ingresso e li raggruppa in un singolo file:

  
  • Webpack : raggruppa tutte le risorse statiche, tra cui JavaScript , immagini, CSS e altro, in un unico file. Consente inoltre di elaborare i file attraverso diversi tipi di caricatori. Puoi scrivere il tuo JavaScript con la syntax dei moduli CommonJS o AMD . Attacca il problema di costruzione in modo fondamentalmente più integrato e ponderato. In Browserify usi Gulp/Grunt e una lunga lista di trasformazioni e plugin per completare il lavoro. Webpack offre abbastanza potenza fuori dalla scatola che in genere non è necessario Grunt o Gulp .

L'utilizzo di base è oltre semplice. Installa Webpack come Browserify:

 npm install -g –save-dev webpack 

E passare il comando un punto di ingresso e un file di output:

 webpack ./entry-point.js bundle-name.js 
  • SystemJS : è un caricatore di moduli in grado di importare moduli in fase di esecuzione in uno dei formati più diffusi oggi ( CommonJS, UMD, AMD, ES6 ). È costruito sopra il polyfill del caricatore dei moduli ES6 ed è abbastanza intelligente da rilevare il formato utilizzato e gestirlo in modo appropriato. SystemJS può anche trascrivere il codice ES6 (con Babel o Traceur ) o altri linguaggi come TypeScript e CoffeeScript usando plugin.

Vuoi sapere qual è il node module del node module e perché non si adatta bene al browser.

Articolo più 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/

Perché jspm e SystemJS ?

Uno degli obiettivi principali della modularità ES6 è rendere semplicissima l'installazione e l'utilizzo di qualsiasi libreria Javascript da qualsiasi posizione su Internet ( Github , npm , ecc.). Sono necessarie solo due cose:

  • Un singolo comando per installare la libreria
  • Una sola riga di codice per importare la libreria e usarla

Quindi con jspm , puoi farlo.

  1. Installa la libreria con un comando: jspm install jquery
  2. Importa la libreria con una singola riga di codice, senza bisogno di riferimenti esterni all'interno del tuo file HTML.

display.js

 var $ = require('jquery'); $('body').append("I've imported jQuery!"); 
  1. Quindi configura queste cose in System.config({ ... }) prima di importare il tuo modulo. Normalmente quando si avvia jspm init , ci sarà un file chiamato config.js per questo scopo.

  2. Per eseguire questi script, è necessario caricare system.js e config.js nella pagina HTML. Successivamente, caricheremo il file display.js utilizzando il caricatore del modulo SystemJS .

index.html

    

Notato: puoi anche usare npm con Webpack come Angular 2 lo ha applicato. Poiché jspm stato sviluppato per integrarsi con SystemJS e funziona in npm sorgente di npm esistente, quindi la tua risposta dipende da te.


3. Runner delle attività

I runner di attività e gli strumenti di compilazione sono principalmente strumenti da riga di comando. Perché dobbiamo usarli: in una parola: automazione . Minore è il lavoro da svolgere quando si eseguono attività ripetitive come minification, compilation, unit test, linting che in passato ci costavano un sacco di volte con la riga di comando o anche manualmente.

  • Grunt : puoi creare automazione per il tuo ambiente di sviluppo per pre-elaborare i codici o creare script di build con un file di configurazione e sembra molto difficile gestire un'attività complessa. Popolare negli ultimi anni.

Ogni attività in Grunt è una serie di diverse configurazioni di plugin, che vengono semplicemente eseguite una dopo l'altra, in modo strettamente indipendente e sequenziale.

 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'automazione è simile a Grunt ma invece di configurazioni, puoi scrivere JavaScript con flussi come se fosse un'applicazione di nodo. Preferisci questi giorni.

Questa è una dichiarazione di attività di esempio di 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); }); 

Vedi di più: https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.fte0nahri


4. Strumenti per l'impalcatura

  • Slush and Yeoman : puoi creare progetti di avviamento con loro. Ad esempio, hai intenzione di build un prototipo con HTML e SCSS, quindi invece di creare manualmente alcune cartelle come scss, css, img, fonts. Puoi semplicemente installare yeoman ed eseguire un semplice script. Allora tutto qui per te.

Trova di più qui .

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

Vedi di più: https://www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express


La mia risposta non è realmente in linea con il contenuto della domanda, ma quando cerco queste informazioni su Google, vedo sempre la domanda in alto in modo tale che ho deciso di rispondere in sintesi. Spero che voi ragazzi l'abbiate trovato utile.

È ansible trovare alcuni confronti tecnici su npmcompare

Confronto tra browserify e grunt vs. gulp vs webpack

Come puoi vedere, il webpack è molto ben mantenuto con una nuova versione che esce ogni 4 giorni in media. Ma Gulp sembra avere la più grande comunità di tutti (con oltre 20.000 stelle su Github) Grunt sembra un po ‘trascurato (rispetto agli altri)

Quindi, se dovessi scegliere l’uno rispetto all’altro, andrei con Gulp

OK, hanno tutti delle somiglianze, fanno le stesse cose per te in modi diversi e simili, li divido in 3 gruppi principali come di seguito:


1) Pacchetti di moduli

webpack e browserify come quelli più popolari, funzionano come task runner ma con maggiore flessibilità, inoltre raggrupperanno tutto insieme come impostazione, quindi puoi puntare al risultato come bundle.js per esempio in un singolo file incluso CSS e Javascript, per maggiori dettagli di ciascuno, guarda i dettagli di seguito:

webpack

webpack è un bundle di moduli per le moderne applicazioni JavaScript. Quando webpack elabora la tua applicazione, ricostruisce ricorsivamente un grafico delle dipendenze che include ogni modulo richiesto dall’applicazione, quindi pacchetti tutti quei moduli in un piccolo numero di bundle, spesso solo uno, che devono essere caricati dal browser.

È incredibilmente configurabile, ma per iniziare devi solo capire i quattro concetti fondamentali: entry, output, caricatori e plug-in.

Questo documento ha lo scopo di fornire una panoramica di alto livello di questi concetti, fornendo allo stesso tempo collegamenti a casi d’uso specifici di concetti dettagliati.

di più qui

browserify

Browserify è uno strumento di sviluppo che ci consente di scrivere moduli node.js in stile da compilare per l’utilizzo nel browser. Proprio come il nodo, scriviamo i nostri moduli in file separati, esportando metodi e proprietà esterne usando il modulo.exporta ed esporta variabili. Possiamo anche richiedere altri moduli usando la funzione require, e se omettiamo il percorso relativo verrà risolto nel modulo nella directory node_modules.

di più qui


2) Corridori di attività

gulp e grunt sono task runner, in pratica quello che fanno, creando attività e eseguendole quando vuoi, ad esempio installando un plug-in per minimizzare il CSS e poi eseguirlo ogni volta per fare minifying, maggiori dettagli su ciascuna:

sorso

gulp.js è un toolkit JavaScript open source di Fractal Innovations e la comunità open source di GitHub, utilizzato come sistema di generazione di streaming nello sviluppo web front-end. È un task runner costruito su Node.js e Node Package Manager (npm), utilizzato per l’automazione di attività lunghe e ripetitive coinvolte nello sviluppo web come minification, concatenazione, cache busting, unit test, linting, ottimizzazione ecc. un approccio di code-over-configuration per definire i suoi compiti e si basa sui suoi piccoli plug-in single-purpose per eseguirli. L’ecosistema di Gulp ha oltre 1000 plug-in messi a disposizione tra cui scegliere.

di più qui

grugnito

Grunt è un runner di attività JavaScript, uno strumento utilizzato per eseguire automaticamente attività di uso frequente come minification, compilation, unit test, linting, ecc. Utilizza un’interfaccia della riga di comando per eseguire attività personalizzate definite in un file (noto come Gruntfile) . Grunt è stato creato da Ben Alman ed è scritto in Node.js. È distribuito via npm. Attualmente, ci sono più di cinquemila plugin disponibili nell’ecosistema di Grunt.

di più qui


3) Gestori di pacchetti

i gestori di pacchetti, ciò che fanno è gestire i plug-in necessari nell’applicazione e installarli per voi tramite github ecc. utilizzando package.json, molto utile per aggiornare i moduli, installarli e condividere la tua app, maggiori dettagli per ciascuno:

npm

npm è un gestore di pacchetti per il linguaggio di programmazione JavaScript. È il gestore pacchetti predefinito per l’ambiente di runtime JavaScript Node.js. Consiste in un client della riga di comando, chiamato anche npm, e un database online di pacchetti pubblici, chiamato registro di npm. Il registro è accessibile tramite il client e i pacchetti disponibili possono essere sfogliati e ricercati tramite il sito Web di npm.

di più qui

pergolato

Bower può gestire componenti che contengono HTML, CSS, JavaScript, caratteri o persino file di immagine. Bower non concatena o minimizza il codice o fa altro, semplicemente installa le giuste versioni dei pacchetti necessari e le loro dipendenze. Per iniziare, Bower funziona recuperando e installando pacchetti da tutto il mondo, occupandosi della caccia, della ricerca, del download e del salvataggio delle cose che stai cercando. Bower tiene traccia di questi pacchetti in un file manifest, bower.json.

di più qui

e il più recente gestore di pacchetti da non perdere, è giovane e veloce in ambiente di lavoro reale rispetto a npm che usavo principalmente prima, per reinstallare i moduli, controlla due volte la cartella node_modules per verificare l’esistenza del modulo, sembra anche che l’installazione dei moduli richieda meno tempo:

filato

Yarn è un gestore di pacchetti per il tuo codice. Ti consente di utilizzare e condividere il codice con altri sviluppatori di tutto il mondo. Il filato lo fa in modo rapido, sicuro e affidabile, così non dovrai mai preoccuparti.

Yarn ti consente di utilizzare le soluzioni di altri sviluppatori per problemi diversi, semplificando lo sviluppo del tuo software. In caso di problemi, è ansible segnalare problemi o contribuire, e quando il problema è risolto, è ansible utilizzare Yarn per mantenere tutto aggiornato.

Il codice è condiviso attraverso qualcosa chiamato un pacchetto (a volte indicato come un modulo). Un pacchetto contiene tutto il codice condiviso e un file package.json che descrive il pacchetto.

di più qui


Una piccola nota su npm: npm3 prova ad installare le dipendenze in modo piatto

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

Che cos’è webpack e webpack-dev-server? La documentazione ufficiale dice che è un modulo bundler ma per me è solo un corridore di compiti. Qual è la differenza?

webpack-dev-server è un web server di ricarica live che gli sviluppatori di Webpack utilizzano per ottenere un feedback immediato su ciò che fanno. Dovrebbe essere usato solo durante lo sviluppo.

Questo progetto è fortemente ispirato dallo strumento di test dell’unità nof5 .

Webpack come suggerisce il nome creerà un SINGLE pack per il web . Il pacchetto verrà ridotto a icona e riunito in un singolo file (viviamo ancora nell’era HTTP 1.1). Webpack fa la magia di combinare le risorse (JavaScript, CSS, immagini) e di iniettarle in questo modo: .

Può anche essere chiamato module bundler perché deve capire le dipendenze dei moduli e come afferrare le dipendenze e raggrupparle insieme.

Dove useresti browserify? Non possiamo fare lo stesso con le importazioni di nodo / ES6?

È ansible utilizzare Browserify nelle stesse identiche attività in cui si utilizzerà Webpack . – Il Webpack è più compatto, però.

Notare che le funzioni di caricamento del modulo ES6 in Webpack2 utilizzano System.import , che non è supportato nativamente da un singolo browser.

Quando useresti gulp / grunt su npm + plugin?

Puoi dimenticare Gulp, Grunt, Brokoli, Brunch e Bower . Utilizza direttamente script di riga di comando npm e puoi eliminare pacchetti extra come questi qui per 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'), 

Probabilmente puoi usare i generatori di file di configurazione Gulp e Grunt durante la creazione di file di configurazione per il tuo progetto. In questo modo non è necessario installare Yeoman o strumenti simili.

Yarn è un recente gestore di pacchetti che probabilmente merita di essere menzionato. Quindi, lì: https://yarnpkg.com/

Afaik, può recuperare entrambe le dipendenze di npm e bower e ha altre caratteristiche apprezzate.

StackShare fornisce uno affiancamento (o impila in pila ) di tre strumenti contemporaneamente.

Qui è per npm vs Bower vs Browserify e per gulp vs Webpack vs Grunt

Su queste pagine di confronto puoi trovare quanto segue:

  • numero di voti ricevuti dalla community StackShare
  • quali aziende li usano nel loro stack tecnologico
  • livello di interesse per ciascuno nel tempo
  • professionisti per ogni strumento

Webpack è un bundler. Come Browserfy , cerca nella base di codice per le richieste di modulo ( require o import ) e le risolve ricorsivamente. Inoltre, è ansible configurare Webpack per risolvere non solo moduli simili a JavaScript, ma CSS, immagini, HTML, letteralmente tutto. Ciò che mi rende particolarmente entusiasta di Webpack , è ansible combinare moduli compilati e caricati dynamicmente nella stessa app. In questo modo si ottiene un reale aumento delle prestazioni, soprattutto su HTTP / 1.x. Come esattamente tu lo fai Descritto con esempi qui http://dsheiko.com/weblog/state-of-javascript-modules-2017/ Come alternativa per il bundler si può pensare a Rollup.js ( https: // rollupjs. org / ), che ottimizza il codice durante la compilazione, ma elimina tutti i blocchi inutilizzati trovati.

Per AMD , invece di RequireJS ansible ES2016 module system nativo, ma caricato con System.js ( https://github.com/systemjs/systemjs )

Inoltre, vorrei sottolineare che npm viene spesso utilizzato come strumento di automazione come grunt o gulp . Controlla https://docs.npmjs.com/misc/scripts . Io personalmente vado ora con gli script npm solo evitando altri strumenti di automazione, anche se in passato ero molto preso in grunt . Con altri strumenti devi contare su innumerevoli plugin per pacchetti, che spesso non sono scritti bene e non vengono mantenuti triggersmente. npm conosce i suoi pacchetti, quindi chiamate qualsiasi pacchetto installato localmente per nome come:

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

In realtà, come regola, non è necessario alcun plug-in se il pacchetto supporta la CLI.