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


1886

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

  • npme bowersiamo gestori di pacchetti. Scaricano semplicemente le dipendenze e non sanno come costruire progetti da soli. Quello che sanno è chiamare webpack/ gulp/ gruntdopo aver recuperato tutte le dipendenze.
  • bowerè come npm, ma costruisce alberi di dipendenza appiattiti (diversamente npmda come lo fa ricorsivamente). Il significato npmrecupera le dipendenze per ciascuna dipendenza (può recuperare lo stesso alcune volte), mentre si boweraspetta che includiate manualmente le dipendenze secondarie. A volte bowere npmsono usati insieme rispettivamente per front-end e back-end (poiché ogni megabyte potrebbe importare in front-end).
  • grunte gulpsono task runner per automatizzare tutto ciò che può essere automatizzato (ad esempio compilare CSS / Sass, ottimizzare le immagini, creare un bundle e minimizzarlo / traspilarlo).
  • gruntvs. gulp(è come mavenvs. gradleo configurazione vs. codice). 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 Node, il che gli consente di costruire catene di tubi (senza riaprire lo stesso file) e renderlo più veloce.
  • webpack( webpack-dev-server) - per me è un corridore di attività con una rapida ricarica delle modifiche che ti consente di dimenticare tutti gli osservatori JS / CSS.
  • npmI bowerplug-in / + possono sostituire i corridori di attività. Le loro abilità spesso si intersecano, quindi ci sono implicazioni diverse se devi usare gulp/ gruntover npm+ plugin. Ma i runner di attività sono sicuramente migliori per attività complesse (ad esempio "su ogni build crea bundle, esegui la transpile da ES6 a ES5, eseguilo su tutti gli emulatori di browser, crea screenshot e distribuisci su dropbox tramite ftp").
  • browserifyconsente il confezionamento di moduli di nodi per i browser. browserifyvs nodes' requireè in realtà AMD vs CommonJS .

Domande:

  1. Che cos'è webpack& webpack-dev-server? La documentazione ufficiale dice che è un modulo bundler ma per me è solo un task runner. Qual è la differenza?
  2. Dove useresti browserify? Non possiamo fare lo stesso con le importazioni del nodo / ES6?
  3. Quando useresti gulp/ gruntover npm+ plugin?
  4. Fornisci esempi quando è necessario utilizzare una combinazione

52
tempo di aggiungere il rollup ? 😝
gman,

167
questa è una domanda molto ragionevole. pseudo web-dev come me si imbattono in tutti i pacchetti che vengono implementati in modo settimanale ..
Simon Dirmeier,


41
@Fisherman Sono totalmente nuovo in questo, e sembra completamente fuori di testa ...
David Stosik,

13
@Fisherman Il commento "consigliato" che ho appena letto è stato anche peggio! D: Voglio solo creare una pagina statica che sfrutti un paio di librerie CSS / JS e trarrebbe beneficio dall'avere uno strumento in grado di compilarlo insieme ... Aggiungi un motore di template per dare un po 'di riposo al mio Ctrl-C / Ctrl-V dita, e sarebbe perfetto ... Eppure, a ore, cerca ancora di trovare un modo per andare ...
David Stosik,

Risposte:


1028

Webpack e Browserify

Webpack e Browserify svolgono praticamente lo stesso lavoro, che sta elaborando il codice da utilizzare in un ambiente di destinazione (principalmente browser, sebbene sia possibile targetizzare altri ambienti come Node). Il risultato di tale elaborazione è uno o più bundle : script assemblati adatti all'ambiente di destinazione.

Ad esempio, supponiamo che tu abbia scritto il codice ES6 diviso in moduli e desideri essere in grado di eseguirlo in un browser. Se tali moduli sono moduli Node, il browser non li capirà poiché esistono solo nell'ambiente Node. Inoltre i moduli ES6 non funzioneranno nei browser più vecchi come IE11. Inoltre, potresti aver usato funzionalità linguistiche sperimentali (prossime proposte di ES) che i browser non implementano ancora, quindi l'esecuzione di tale script genererebbe solo errori. Strumenti come Webpack e Browserify risolvono questi problemi traducendo tale codice in una forma che un browser è in grado di eseguire . Inoltre, consentono di applicare una grande varietà di ottimizzazioni su questi pacchetti.

Tuttavia, Webpack e Browserify differiscono in molti modi, Webpack offre molti strumenti per impostazione predefinita (ad esempio la suddivisione del codice), mentre Browserify può farlo solo dopo aver scaricato i plug-in ma utilizzando entrambi porta a risultati molto simili . Dipende dalle preferenze personali (Webpack è più trendy). A proposito, Webpack non è un task runner, è solo un elaboratore di file (li elabora con i cosiddetti caricatori e plugin) e può essere eseguito (tra l'altro) da un runner di task.


Webpack Dev Server

Webpack Dev Server fornisce una soluzione simile a Browsersync: un server di sviluppo in cui è possibile distribuire rapidamente l'app mentre ci si sta lavorando e verificare immediatamente l'avanzamento dello sviluppo, con il server dev che aggiorna automaticamente il browser in caso di modifiche al codice o addirittura propaga il codice modificato al browser senza ricaricare con la cosiddetta sostituzione del modulo a caldo.


Runner di attività vs script NPM

Ho usato Gulp per la sua concisione e la sua semplice scrittura di compiti, ma in seguito ho scoperto che non ho bisogno né di Gulp né di Grunt. Tutto ciò di cui ho mai avuto bisogno avrebbe potuto essere fatto usando gli script NPM per eseguire strumenti di terze parti attraverso la loro API. La scelta tra script Gulp, Grunt o NPM dipende dal gusto e dall'esperienza del tuo team.

Mentre i compiti 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 da imparare e personalmente preferisco restringere le mie dipendenze e semplificare le cose. D'altra parte, sostituire questi compiti con la combinazione di script NPM e (probabilmente JS) che eseguono quegli strumenti di terze parti (es. Script di nodi che configurano ed eseguono rimraf per scopi di pulizia) potrebbe essere più impegnativo. Ma nella maggior parte dei casi, questi tre sono uguali in termini di risultati.


Esempi

Per quanto riguarda gli esempi, ti suggerisco di dare un'occhiata a questo progetto di avvio di React , che mostra una bella combinazione di script NPM e JS che coprono l'intero processo di compilazione e distribuzione. Puoi trovare quegli script NPM nella package.jsoncartella principale, in una proprietà denominata scripts. Lì incontrerai principalmente comandi come babel-node tools/run start. Babel-node è uno strumento CLI (non destinato alla produzione), che inizialmente compila il file ES6 tools/run(file run.js che si trova negli strumenti ), sostanzialmente un'utilità di esecuzione . Questo runner accetta una funzione come argomento e la esegue, che in questo caso è start- un'altra utilità (start.js) responsabile del raggruppamento dei file di origine (sia client che server) e dell'avvio dell'applicazione e del server di sviluppo (il server di sviluppo sarà probabilmente Webpack Dev Server o Browsersync).

Parlando in modo più preciso, start.jscrea pacchetti sia lato client che lato server, avvia un server espresso e dopo un avvio riuscito inizializza la sincronizzazione del browser, che al momento della scrittura appariva così (fare riferimento al progetto di avvio 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 proxy, che potrebbe essere http: // localhost: 3000 , e Browsersync avvia un server in ascolto su http: // localhost: 3001 , dove le risorse generate vengono servite con cambio automatico rilevazione e sostituzione del modulo a caldo. Come puoi vedere, c'è un'altra proprietà di configurazione filescon singoli file o modelli La sincronizzazione del browser controlla le modifiche e ricarica il browser se si verificano alcuni, ma come dice il commento, Webpack si occupa di guardare le fonti js da solo con HMR, quindi collaborano Là.

Ora non ho alcun esempio equivalente di tale configurazione di Grunt o Gulp, ma con Gulp (e in qualche modo in modo simile con Grunt) scriveresti 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 avresti praticamente fatto le stesse cose dello starter kit, 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 ho detto, il più dipendenze hai, più può andare storto. E questa è la ragione per cui mi piace liberarmi di tali strumenti.


3
Bella risposta! Puoi descrivere i pls in che modo webpack / browserify gestiscono i moduli del nodo di riutilizzo nel browser, per favore?
VB_

4
Webpack assembla le dipendenze (valori dei moduli esportati) in oggetto (moduli installati). Ogni modulo è quindi proprietà di quell'oggetto e il nome di tale proprietà rappresenta il suo id (es. 1, 2, 3 ... ecc.). Ogni volta che si richiede tale modulo nel proprio sorgente, webpack trasforma il valore in chiamata di funzione con l'ID del modulo nell'argomento (ad es. __Webpack_require __ (1)), che restituisce la dipendenza corretta in base alla ricerca nei moduli installati per ID modulo. Non sono sicuro di come Browserify lo gestisca.
Dan Macák,

@Dan Skočdopole Puoi approfondire?
Asim KT,

1
Non sono d'accordo con la presentazione dell'uso di base di gulp o grunt, questi due sono facili da confrontare usando google, webpack-dev-server richiede di capire prima il webpack, e questo è fuori dalla portata di questa domanda / risposta, ma ho presentato alcune configurazioni di Browsersync. Hai ragione con lo starter-kit e ho approfondito di più.
Dan Macák,

5
+1 per ridurre le dipendenze per mantenere le cose semplici anziché seguire l'opinione (più) popolare che ogni nuovo pacchetto deve essere usato!
madannes,

675

Aggiornamento ottobre 2018

Se non sei ancora sicuro dello sviluppo del front-end, puoi dare un'occhiata veloce a una risorsa eccellente qui.

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

Aggiornamento giugno 2018

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

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 Grab su come affrontare lo sviluppo front-end nel 2017. Puoi verificarlo come di seguito.

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


Ho anche cercato 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 in strumenti come Browserify, Webpack, jspm, Grunt and Gulp. Potresti anche sentirne parlare Yeoman or Slush. Questo non è davvero un problema, è solo confuso per tutti coloro che cercano di capire un chiaro percorso in avanti.

Ad ogni modo, vorrei contribuire con qualcosa.

1. Gestore pacchetti

I gestori pacchetti semplificano l'installazione e l'aggiornamento delle dipendenze del progetto, che sono librerie come:, jQuery, Bootstrapecc., Tutto ciò che viene utilizzato sul tuo sito e non è stato scritto da te.

Navigare in tutti i siti Web delle biblioteche, scaricare e decomprimere gli archivi, copiare i file nei progetti: tutto questo viene sostituito con alcuni comandi nel terminale.

  • NPMsta per: Node JS package managerti aiuta a gestire tutte le librerie su cui si basa il tuo software. Definiresti le tue esigenze in un file chiamato package.jsoned eseguito npm installnella riga di comando ... quindi BANG, i tuoi pacchetti vengono scaricati e pronti per l'uso. Potrebbe essere usato sia per le front-end and back-endbiblioteche.

  • Bower: per la gestione dei pacchetti front-end, il concetto è lo stesso con NPM. Tutte le librerie vengono archiviate in un file denominato bower.jsone quindi eseguite bower installnella riga di comando.

La differenza più grande tra Bowere NPMè che NPM fa un albero delle dipendenze nidificato mentre Bower richiede un albero delle dipendenze piatto come di seguito.

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 npm 3 Duplication and Deduplication, per favore apri il documento per maggiori dettagli.

  • Yarn: Un nuovo gestore di pacchetti JavaScript pubblicato di Facebookrecente con alcuni più vantaggi rispetto a NPM. E con Filati, è ancora possibile utilizzare entrambi NPMe BowerRegistro di sistema per recuperare il pacchetto. Se hai già installato un pacchetto in precedenza, yarncrea una copia cache che facilita offline package installs.

  • jspm: è un gestore di pacchetti per il SystemJScaricatore di moduli universale, costruito sopra il ES6caricatore di moduli dinamici . Non è un gestore di pacchetti completamente nuovo con un proprio set di regole, ma funziona al di sopra delle fonti di pacchetti esistenti. Fuori dalla scatola, funziona con GitHube npm. Poiché la maggior parte dei Bowerpacchetti basati si basa GitHub, possiamo installare anche quei pacchetti jspm. Ha un registro che elenca la maggior parte dei pacchetti front-end comunemente usati per una più facile installazione.

Guarda le differenze tra Bowere jspm: Package Manager: Bower vs jspm


2. Caricatore / raggruppamento di moduli

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

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

Per esempio

<head>
    <title>Wagon</title>
    <script src=“build/wagon-bundle.js”></script>
</head>
  • La prestazione viene però a scapito della flessibilità. Se i tuoi moduli hanno interdipendenza, questa mancanza di flessibilità potrebbe essere uno spettacolo.

Per esempio

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

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

Poi abbiamo sentito parlare RequireJS, Browserify, WebpackeSystemJS

  • RequireJS: è un JavaScriptcaricatore di file e moduli. È ottimizzato per l'uso nel browser, ma può essere utilizzato in altri ambienti JavaScript, come 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.jscome dipendenza e usarlo.

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

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

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

Maggiori informazioni su CommonJSe AMDper capire facilmente. Relazione tra CommonJS, AMD e RequireJS?

  • Browserify: impostato per consentire l'uso di CommonJSmoduli formattati nel browser. Di conseguenza, Browserifynon è tanto un modulo loader quanto un modulo bundler: Browserifyè interamente uno strumento di build-time, che produce un pacchetto di codice che può quindi essere caricato sul lato client.

Inizia con un computer di build su cui sono installati node & npm e ottieni il pacchetto:

npm install -g save-dev browserify

Scrivi i tuoi moduli in CommonJSformato

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

E quando sei felice, emetti il ​​comando per raggruppare:

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

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

<script src=”bundle-name.js”></script>
  • Webpack: Raggruppa tutte le risorse statiche, tra cui JavaScriptimmagini, CSS e altro, in un unico file. Inoltre, consente di elaborare i file attraverso diversi tipi di caricatori. È possibile scrivere la sintassi JavaScriptcon CommonJSo dei AMDmoduli. Attacca il problema della costruzione in modo sostanzialmente più integrato e supponente. In Browserifyte usi Gulp/Grunte un lungo elenco di trasformazioni e plugin per portare a termine il lavoro. Webpackoffre abbastanza potenza pronta all'uso che in genere non è necessaria Grunto Gulpaffatto.

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

npm install -g save-dev webpack

E passa al comando un punto di ingresso e un file di output:

webpack ./entry-point.js bundle-name.js
  • SystemJS: è un caricatore di moduli che può importare moduli in fase di esecuzione in uno dei formati più utilizzati oggi ( CommonJS, UMD, AMD, ES6). È costruito sulla parte superiore del ES6polyfill del caricatore del modulo ed è abbastanza intelligente da rilevare il formato utilizzato e gestirlo in modo appropriato. SystemJSpuò anche trascrivere il codice ES6 (con Babelo Traceur) o altre lingue come TypeScripte CoffeeScriptusando plugin.

Vuoi sapere cos'è node modulee perché non è ben adattato al browser.

Articolo più utile:


Perché jspme SystemJS?

Uno dei principali obiettivi di ES6modularità è quello di rendere davvero semplice da installare e utilizzare qualsiasi libreria JavaScript da qualsiasi luogo su Internet ( Github, npm, ecc). Sono necessarie solo due cose:

  • Un singolo comando per installare la libreria
  • Una singola riga di codice per importare la libreria e utilizzarla

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 configurare queste cose all'interno System.config({ ... })prima di importare il modulo. Normalmente quando eseguito jspm init, ci sarà un file chiamato config.jsper questo scopo.

  2. Per eseguire questi script, è necessario caricare system.jse config.jsnella pagina HTML. Successivamente cariceremo il display.jsfile utilizzando il SystemJScaricatore del modulo.

index.html

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

Nota: puoi anche usarlo npmcon WebpackAngular 2. Dal momento che è jspmstato sviluppato per integrarsi con SystemJSe funziona sulla npmfonte esistente , quindi la tua risposta dipende da te.


3. Task runner

I gestori di attività e gli strumenti di creazione sono principalmente strumenti da riga di comando. Perché dobbiamo usarli: in una parola: automazione . Meno lavoro devi fare quando esegui attività ripetitive come la minificazione, la compilazione, il test delle unità, i peli che in precedenza ci sono costati molte volte da fare con la riga di comando o anche manualmente.

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

Ogni attività in Gruntè una matrice 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 è come, Gruntma invece delle configurazioni, puoi scrivere JavaScriptcon flussi come se fosse un'applicazione nodo. Preferisco questi giorni.

Questa è una Gulpdichiarazione di attività di esempio.

//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);
});

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


4. Strumenti per ponteggi

  • Slush and Yeoman: È possibile creare progetti di avvio con loro. Ad esempio, stai pianificando di costruire un prototipo con HTML e SCSS, quindi invece di creare manualmente alcune cartelle come scss, css, img, fonts. Puoi semplicemente installare yeomaned eseguire uno script semplice. Quindi tutto qui per te.

Scopri 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 abbinata al contenuto della domanda, ma quando cerco queste informazioni su Google, vedo sempre la domanda in cima, così ho deciso di rispondere in sintesi. Spero che abbiate trovato utile.


64

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


1) Bundle di moduli

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

webpack

webpack è un modulo bundler per le moderne applicazioni JavaScript. Quando il webpack elabora la tua applicazione, crea ricorsivamente un grafico delle dipendenze che include tutti i moduli necessari per la tua applicazione, quindi impacchetta tutti quei moduli in un piccolo numero di bundle - spesso solo uno - per essere caricati dal browser.

È incredibilmente configurabile, ma per iniziare devi solo capire quattro concetti fondamentali: ingresso, uscita, caricatori e plugin.

Questo documento ha lo scopo di fornire una panoramica di alto livello di questi concetti, fornendo al contempo collegamenti a casi d'uso dettagliati specifici.

di più qui

browserify

Browserify è uno strumento di sviluppo che ci consente di scrivere moduli in stile node.js che vengono compilati per l'uso nel browser. Proprio come il nodo, scriviamo i nostri moduli in file separati, esportando metodi e proprietà esterni usando le variabili module.exports ed export. Possiamo anche richiedere altri moduli usando la funzione request e se omettiamo il percorso relativo, si risolverà nel modulo nella directory node_modules.

di più qui


2) Task runner

gulp e grunt sono gestori di attività, sostanzialmente ciò che fanno, creando attività ed eseguendole ogni volta che vuoi, ad esempio installi un plugin per minimizzare il tuo CSS e poi eseguilo ogni volta per eseguire la minimizzazione, maggiori dettagli su ciascuno:

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 basato su Node.js e Node Package Manager (npm), utilizzato per l'automazione di attività ripetitive e dispendiose in termini di tempo nello sviluppo web come minimizzazione, concatenazione, busting della cache, unit test, linting, ottimizzazione ecc. Utilizza gulp un approccio code-over-configuration per definire i suoi compiti e si affida ai suoi piccoli plugin a scopo singolo per eseguirli. gulp ecosystem ha 1000+ plug-in di questo tipo resi disponibili tra cui scegliere.

di più qui

grugnito

Grunt è un task runner JavaScript, uno strumento utilizzato per eseguire automaticamente attività utilizzate di frequente come minificazione, compilazione, 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 tramite npm. Attualmente, ci sono più di cinquemila plugin disponibili nell'ecosistema Grunt.

di più qui


3) Gestori di pacchetti

gestori di pacchetti, ciò che fanno è gestire i plugin di cui hai bisogno nella tua applicazione e installarli tramite github ecc. usando package.json, molto utile per aggiornare i tuoi moduli, installarli e condividere la tua app attraverso, 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. È costituito da un client della riga di comando, chiamato anche npm, e da un database online di pacchetti pubblici, chiamato registro npm. È possibile accedere al registro tramite il client e i pacchetti disponibili possono essere sfogliati e cercati tramite il sito Web npm.

di più qui

pergolato

Bower può gestire componenti che contengono HTML, CSS, JavaScript, caratteri o persino file di immagini. Bower non concatena o minimizza il codice né fa altro: installa semplicemente le versioni giuste dei pacchetti necessari e le relative dipendenze. Per iniziare, Bower funziona recuperando e installando pacchetti da ogni parte, occupandosi della caccia, della ricerca, del download e del salvataggio dei contenuti 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 un ambiente di lavoro reale rispetto a npm che stavo usando 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 codice con altri sviluppatori di tutto il mondo. Filato lo fa in modo rapido, sicuro e affidabile, così non dovrai mai preoccuparti.

Yarn ti consente di utilizzare soluzioni di altri sviluppatori per problemi diversi, facilitando lo sviluppo del tuo software. In caso di problemi, è possibile segnalare problemi o contribuire indietro e, quando il problema è stato risolto, è possibile utilizzare Filato per mantenerlo aggiornato.

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

di più qui



C'è un elenco di plugin gulp? ce ne sono davvero 1000+? npm restituisce solo 20 o giù di lì?
flurbius,

1
Ottimo riassunto. Dovrebbe essere un punto di accesso per qualsiasi discussione su uno sviluppo web moderno.
Adam Bubela,

1
@flurbius Sì, qui: gulpjs.com/plugins . Attualmente sembrano esserci 3.465 plugin Gulp.
martedì

52

Puoi trovare alcuni confronti tecnici su npmcompare

Confronto tra browserify e grunt vs. gulp vs webpack

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

Quindi, se ho bisogno di sceglierne uno, andrei con Gulp


5
webpack ora è 26k inizia su Github e gulp con 25,7k. Non posso più usare il fattore popolarità per decidere ...
Rayee Roded


14

Che cos'è webpack e webpack-dev-server? La documentazione ufficiale dice che è un modulo bundler ma per me è solo un task runner. Qual è la differenza?

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

Questo progetto è fortemente ispirato allo strumento di test unitario nof5 .

Webpack come suggerisce il nome creerà un SINGOLO pacchetto per il web . Il pacchetto verrà ridotto a icona e combinato in un singolo file (viviamo ancora nell'era HTTP 1.1). Webpack fa la magia di combinare le risorse (JavaScript, CSS, immagini) e l'iniezione in questo modo: <script src="assets/bundle.js"></script>.

Può anche essere chiamato modulo bundler perché deve comprendere le dipendenze del modulo e come afferrare le dipendenze e raggrupparle insieme.

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

Puoi utilizzare Browserify sulle stesse identiche attività in cui utilizzeresti Webpack . - Webpack è però più compatto.

Si noti che le funzionalità di caricamento del modulo ES6 in Webpack2 utilizzano System.import , che non supporta un singolo browser in modo nativo.

Quando useresti gulp / grunt su npm + plugin?

Puoi dimenticare Gulp, Grunt, Brokoli, Brunch e Bower . Utilizza direttamente invece gli script da 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 quando crei file di configurazione per il tuo progetto. In questo modo non è necessario installare Yeoman o strumenti simili.


14

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

Per quanto ne so, può recuperare dipendenze sia da npm che da bower e ha altre caratteristiche apprezzate.


12

Webpackè un bundler. Come Browserfyse cercasse nel codebase richieste di moduli ( requireo import) e le risolvesse in modo ricorsivo. Inoltre, puoi configurare Webpackper risolvere non solo moduli simili a JavaScript, ma CSS, immagini, HTML, letteralmente tutto. Ciò che mi rende particolarmente entusiasta Webpack, è possibile combinare moduli compilati e caricati dinamicamente nella stessa app. In questo modo si ottiene un vero aumento delle prestazioni, soprattutto su HTTP / 1.x. Come esattamente lo fai ho descritto qui con esempi http://dsheiko.com/weblog/state-of-javascript-modules-2017/ In alternativa al bundler si può pensare a Rollup.js( https://rollupjs.org/ ) , che ottimizza il codice durante la compilazione, ma rimuove tutti i blocchi non utilizzati trovati.

Per AMD, invece di RequireJSuno può andare con nativo ES2016 module system, ma caricato con System.js( https://github.com/systemjs/systemjs )

Inoltre, vorrei sottolineare che npmviene spesso utilizzato come strumento di automazione come grunto gulp. Dai un'occhiata a https://docs.npmjs.com/misc/scripts . Personalmente vado ora con gli script npm evitando solo altri strumenti di automazione, anche se in passato ero molto interessato grunt. Con altri strumenti devi fare affidamento su innumerevoli plugin per i pacchetti, che spesso non sono scritti bene e non vengono mantenuti attivamente. npmconosce i suoi pacchetti, quindi chiami uno qualsiasi dei pacchetti installati localmente per nome come:

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

In realtà, di norma non è necessario alcun plug-in se il pacchetto supporta l'interfaccia della riga di comando.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.