Le seguenti sezioni descrivono i principali cambiamenti da webpack 1 a 2.

resolve.root, resolve.fallback, resolve.modulesDirectories

Queste opzioni sono state sostituite da una singola opzione resolve.modules. Vedere resolving per ulteriori usi.

 resolve: {- root: path.join(__dirname, "src")+ modules: }

resolve.extensions

Questa opzione non richiede più di passare una stringa vuota. Questo comportamento è stato spostato in resolve.enforceExtension. Vedere resolving per ulteriori usi.

resolve.*

Diverse API sono state cambiate qui. Non elencate in dettaglio perché non sono comunemente usate. Vedere resolving per i dettagli.

module.loaders è ora module.rules

La vecchia configurazione del caricatore è stata sostituita da un sistema di regole più potente, che permette la configurazione dei caricatori e altro. Per ragioni di compatibilità, la vecchia sintassi module.loaders è ancora valida e i vecchi nomi vengono analizzati. Le nuove convenzioni di denominazione sono più facili da capire e sono una buona ragione per aggiornare la configurazione utilizzando module.rules.

 module: {- loaders: }, { test: /\.jsx$/, loader: "babel-loader", // Do not use "use" here options: { // ... } } ] }

Catenamento dei caricatori

Come in webpack 1, i caricatori possono essere concatenati per passare risultati da caricatore a caricatore. Usando l’opzione di configurazione rule.use, use può essere impostato a un array di caricatori. In webpack 1, i caricatori erano comunemente concatenati con !. Questo stile è supportato solo usando l’opzione legacy module.loaders.

 module: {- loaders: }] }

Estensione automatica del nome del modulo del caricatore rimossa

Non è più possibile omettere l’estensione -loader quando si fa riferimento ai caricatori:

 module: { rules: } ] }

È ancora possibile scegliere il vecchio comportamento con l’opzione di configurazione resolveLoader.moduleExtensions, ma non è raccomandato.

+ resolveLoader: {+ moduleExtensions: + }

Vedi #2986 per la ragione di questo cambiamento.

json-loader non è più richiesto

Quando nessun caricatore è stato configurato per un file JSON, webpack cercherà automaticamente di caricare il file JSON con il json-loader.

 module: { rules: }

Abbiamo deciso di fare questo per appianare le differenze di ambiente tra webpack, node.js e browserify.

I caricatori nella configurazione risolvono relativamente al contesto

In webpack 1, i caricatori configurati risolvono relativamente al file abbinato. Tuttavia, in webpack 2, i caricatori configurati si risolvono relativamente all’opzione context.

Questo risolve alcuni problemi con i moduli duplicati causati dai caricatori quando si usa npm link o si fa riferimento a moduli al di fuori del context.

Si possono rimuovere alcuni hack per lavorare intorno a questo:

 module: { rules: }, resolveLoader: {- root: path.resolve(__dirname, "node_modules") }

module.preLoaders e module.postLoaders sono stati rimossi:

 module: {- preLoaders: }

UglifyJsPlugin sourceMap

L’opzione sourceMap del UglifyJsPlugin ora ha come default false invece di true. Questo significa che se stai usando le mappe dei sorgenti per il codice minimizzato o vuoi i numeri di linea corretti per gli avvertimenti di uglifyjs, devi impostare sourceMap: true per UglifyJsPlugin.

 devtool: "source-map", plugins: 

UglifyJsPlugin warnings

L’opzione compress.warnings del UglifyJsPlugin ora ha come default false invece di true. Questo significa che se vuoi vedere gli avvertimenti di uglifyjs, devi impostare compress.warnings a true.

 devtool: "source-map", plugins: 

UglifyJsPlugin minimizza i caricatori

UglifyJsPlugin non commuta più i caricatori in modalità minimizza. L’impostazione minimize: true deve essere passata tramite le opzioni del caricatore a lungo termine. Vedere la documentazione del caricatore per le opzioni pertinenti.

La modalità di minimizzazione per i caricatori sarà rimossa in webpack 3 o successivo.

Per mantenere la compatibilità con i vecchi caricatori, i caricatori possono essere passati alla modalità di minimizzazione tramite il plugin:

 plugins: 

DedupePlugin è stato rimosso

webpack.optimize.DedupePlugin non è più necessario. Rimuovilo dalla tua configurazione.

BannerPlugin – cambiamento di rottura

BannerPlugin non accetta più due parametri, ma un singolo oggetto opzioni.

 plugins: 

OccurrenceOrderPlugin è ora attivato di default

Il OccurrenceOrderPlugin è ora attivato di default ed è stato rinominato (OccurenceOrderPlugin in webpack 1). Assicurati quindi di rimuovere il plugin dalla tua configurazione:

 plugins: 

ExtractTextWebpackPlugin – cambiamento di rottura

ExtractTextPlugin richiede la versione 2 per funzionare con webpack 2.

npm install --save-dev extract-text-webpack-plugin

I cambiamenti di configurazione per questo plugin sono principalmente sintattici.

module: { rules: }

new ExtractTextPlugin({options})

plugins: 

Le richieste dinamiche complete ora falliscono per default

Una dipendenza con solo un’espressione (es. require(expr)) ora creerà un contesto vuoto invece del contesto della directory completa.

Codice come questo dovrebbe essere ritoccato perché non funziona con i moduli ES2015. Se questo non è possibile potete usare il ContextReplacementPlugin per suggerire al compilatore la risoluzione corretta.

Usare argomenti personalizzati nella CLI e nella configurazione

Se avete abusato della CLI per passare argomenti personalizzati alla configurazione in questo modo:

webpack --custom-stuff

// webpack.config.jsvar customStuff = process.argv.indexOf('--custom-stuff') >= 0;/* ... */module.exports = config;

Potreste notare che questo non è più permesso. La CLI è più rigorosa ora.

Invece c’è un’interfaccia per passare argomenti alla configurazione. Questo dovrebbe essere usato al suo posto. Gli strumenti futuri potrebbero fare affidamento su questo.

webpack --env.customStuff

module.exports = function (env) { var customStuff = env.customStuff; /* ... */ return config;};

Vedi CLI.

require.ensure e AMD require sono asincroni

Queste funzioni sono ora sempre asincrone invece di chiamare il loro callback sincrono se il chunk è già caricato.

require.ensure ora dipende dai Promise nativi. Se usi require.ensure in un ambiente che ne è privo, avrai bisogno di un polyfill.

La configurazione del caricatore avviene attraverso le opzioni

Non puoi più configurare un caricatore con una proprietà personalizzata nel webpack.config.js. Deve essere fatto attraverso il options. La seguente configurazione con la proprietà ts non è più valida con webpack 2:

module.exports = { //... module: { rules: , }, // does not work with webpack 2 ts: { transpileOnly: false },};

Cosa sono le opzioni?

Buona domanda. Beh, in senso stretto sono 2 cose possibili; entrambi i modi di configurare un caricatore webpack. Classicamente options era chiamato query ed era una stringa che poteva essere aggiunta al nome del caricatore. Molto simile a una stringa di query, ma con maggiori poteri:

module.exports = { //... module: { rules: , },};

Ma può anche essere un oggetto specificato separatamente che viene fornito insieme a un caricatore:

module.exports = { //... module: { rules: , },};

LoaderOptionsPlugin context

Alcuni caricatori hanno bisogno di informazioni sul contesto e le leggono dalla configurazione. Questo deve essere passato tramite le opzioni del caricatore nel lungo periodo. Vedere la documentazione del caricatore per le opzioni pertinenti.

Per mantenere la compatibilità con i vecchi caricatori, queste informazioni possono essere passate tramite plugin:

 plugins: 

debug

L’opzione debug ha commutato i caricatori in modalità debug in webpack 1. Questo deve essere passato tramite le opzioni del caricatore a lungo termine. Vedere la documentazione del caricatore per le opzioni pertinenti.

La modalità di debug per i caricatori sarà rimossa in webpack 3 o successivo.

Per mantenere la compatibilità con i vecchi caricatori, i caricatori possono essere commutati in modalità debug tramite un plugin:

- debug: true, plugins: 

Code Splitting con ES2015

In webpack 1, si poteva usare require.ensure() come metodo per caricare pigramente dei chunk per la propria applicazione:

require.ensure(, function (require) { var foo = require('./module');});

La specifica ES2015 Loader definisce import() come metodo per caricare dinamicamente i moduli ES2015 a runtime. webpack tratta import() come uno split-point e mette il modulo richiesto in un chunk separato. import() prende il nome del modulo come argomento e restituisce una Promessa.

function onClick() { import('./module') .then((module) => { return module.default; }) .catch((err) => { console.log('Chunk loading failed'); });}

Buone notizie: Il fallimento nel caricare un chunk può ora essere gestito perché sono basati su Promise.

Espressioni dinamiche

È possibile passare un’espressione parziale a import(). Questo è gestito in modo simile alle espressioni in CommonJS (webpack crea un contesto con tutti i possibili file).

import() crea un chunk separato per ogni possibile modulo.

function route(path, query) { return import(`./routes/${path}/route`).then( (route) => new route.Route(query) );}// This creates a separate chunk for each possible route

Miscelazione di ES2015 con AMD e CommonJS

Come per AMD e CommonJS è possibile mescolare liberamente tutti e tre i tipi di modulo (anche all’interno dello stesso file). webpack si comporta in modo simile a babel e node-eps in questo caso:

// CommonJS consuming ES2015 Modulevar book = require('./book');book.currentPage;book.readPage();book.default === 'This is a book';

// ES2015 Module consuming CommonJSimport fs from 'fs'; // module.exports map to defaultimport { readFileSync } from 'fs'; // named exports are read from returned object+typeof fs.readFileSync === 'function';typeof readFileSync === 'function';

È importante notare che vorrete dire a Babel di non analizzare questi simboli del modulo in modo che webpack possa usarli. Puoi farlo impostando quanto segue nelle tue opzioni .babelrc o babel-loader.

.babelrc

{ "presets": ]}

Suggerimenti

Non c’è bisogno di cambiare qualcosa, ma opportunità

Template strings

webpack ora supporta le template strings nelle espressioni. Questo significa che puoi iniziare ad usarle nei costrutti di webpack:

- require("./templates/" + name);+ require(`./templates/${name}`);

Configuration Promise

webpack ora supporta la restituzione di un Promise dal file di configurazione. Questo permette l’elaborazione asincrona nel tuo file di configurazione.

webpack.config.js

module.exports = function () { return fetchLangs().then((lang) => ({ entry: '...', // ... plugins: , }));};

Corrispondenza avanzata del caricatore

webpack ora supporta più cose da abbinare ai caricatori.

module.exports = { //... module: { rules: , },};

Più opzioni CLI

Ci sono alcune nuove opzioni CLI da usare:

--define process.env.NODE_ENV="production" Vedi DefinePlugin.

--display-depth visualizza la distanza dal punto di ingresso per ogni modulo.

--display-used-exports visualizza le informazioni su quali esportazioni sono usate in un modulo.

--display-max-modules imposta il numero di moduli visualizzati nell’output (predefinito a 15).

-p definisce anche process.env.NODE_ENV a "production" ora.

Modifiche al caricatore

Modifiche rilevanti solo per gli autori del caricatore.

Cacheable

I caricatori sono ora cacheable per default. I caricatori devono rinunciare se non sono cacheable.

 // Cacheable loader module.exports = function(source) {- this.cacheable(); return source; }

 // Not cacheable loader module.exports = function(source) {+ this.cacheable(false); return source; }

Opzioni complesse

webpack 1 supporta solo le opzioni JSON.stringify-able per i caricatori.

webpack 2 ora supporta qualsiasi oggetto JS come opzioni del caricatore.