De följande avsnitten beskriver de viktigaste ändringarna från webpack 1 till 2.

resolve.root, resolve.fallback, resolve.modulesDirectories

De här alternativen har ersatts av ett enda alternativ resolve.modules. Se resolving för mer användning.

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

resolve.extensions

Detta alternativ kräver inte längre att en tom sträng överförs. Detta beteende flyttades till resolve.enforceExtension. Se resolving för mer användning.

resolve.*

Flera API:er ändrades här. Listas inte i detalj eftersom det inte är vanligt förekommande. Se resolving för mer information.

module.loaders är nu module.rules

Den gamla lastarkonfigurationen ersattes av ett kraftfullare regelsystem, som gör det möjligt att konfigurera lastare med mera. Av kompatibilitetsskäl är den gamla module.loaders-syntaxen fortfarande giltig och de gamla namnen analyseras. De nya namnkonventionerna är lättare att förstå och är en bra anledning att uppgradera konfigurationen till att använda module.rules.

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

Kedja laddare

Likt i webpack 1 kan laddare kedjas för att skicka resultat från laddare till laddare. Med hjälp av konfigurationsalternativet rule.use kan use sättas till en array av laddare. I webpack 1 var det vanligt att lastare kedjades med !. Denna stil stöds endast med hjälp av det gamla alternativet module.loaders.

 module: {- loaders: }] }

Automatisk -loader module name extension removed

Det är inte längre möjligt att utelämna -loader-tillägget när man hänvisar till loaders:

 module: { rules: } ] }

Du kan fortfarande välja det gamla beteendet med konfigurationsalternativet resolveLoader.moduleExtensions, men detta rekommenderas inte.

+ resolveLoader: {+ moduleExtensions: + }

Se #2986 för orsaken till denna ändring.

json-loader krävs inte längre

När ingen loader har konfigurerats för en JSON-fil kommer webpack automatiskt att försöka ladda JSON-filen med json-loader.

 module: { rules: }

Vi bestämde oss för att göra detta för att utjämna miljöskillnader mellan webpack, node.js och browserify.

Laddare i konfiguration löser upp relativt till kontext

I webpack 1 löser konfigurerade laddare upp relativt till den matchade filen. I webpack 2 löser dock konfigurerade lastare relativt till context-alternativet.

Detta löser vissa problem med dubbla moduler som orsakas av lastare när man använder npm link eller hänvisar till moduler utanför context.

Du kan ta bort några hack för att komma runt det här:

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

module.preLoaders och module.postLoaders har tagits bort:

 module: {- preLoaders: }

UglifyJsPlugin sourceMap

Objektet sourceMap i UglifyJsPlugin har nu som standardvärde false istället för true. Detta innebär att om du använder källkodsmappningar för minimerad kod eller vill ha korrekta radnummer för uglifyjs-varningar måste du ställa in sourceMap: true för UglifyJsPlugin.

 devtool: "source-map", plugins: 

UglifyJsPlugin varnings

Optionen compress.warnings i UglifyJsPlugin har nu som standard false i stället för true. Detta innebär att om du vill se uglifyjs-varningar måste du ställa in compress.warnings till true.

 devtool: "source-map", plugins: 

UglifyJsPlugin minimize loaders

UglifyJsPlugin växlar inte längre in loaders i minimize-läge. Inställningen minimize: true måste överföras via laddningsalternativ på lång sikt. Se loader-dokumentationen för relevanta alternativ.

Minimera läget för loaders kommer att tas bort i webpack 3 eller senare.

För att bibehålla kompatibiliteten med gamla loaders kan loaders växlas till minimera läget via insticksmodulen:

 plugins: 

DedupePlugin har tagits bort

webpack.optimize.DedupePlugin behövs inte längre. Ta bort den från din konfiguration.

BannerPlugin – brytningsändring

BannerPlugin accepterar inte längre två parametrar, utan ett enda optionsobjekt.

 plugins: 

OccurrenceOrderPlugin är nu aktiverad som standard

The OccurrenceOrderPlugin är nu aktiverad som standard och har bytt namn (OccurenceOrderPlugin i webpack 1). Se därför till att ta bort insticksprogrammet från din konfiguration:

 plugins: 

ExtractTextWebpackPlugin – breaking change

ExtractTextPlugin kräver version 2 för att fungera med webpack 2.

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

Konfigurationsändringarna för det här insticksprogrammet är huvudsakligen syntaktiska.

module: { rules: }

new ExtractTextPlugin({options})

plugins: 

Fullt dynamiskt krav misslyckas nu som standard

Ett beroende med endast ett uttryck (dvs. require(expr)) kommer nu att skapa en tom kontext i stället för kontexten för hela katalogen.

Kod som den här typen av kod bör omarbetas eftersom den inte fungerar med ES2015-moduler. Om detta inte är möjligt kan du använda ContextReplacementPlugin för att ge kompilatorn en vink om rätt upplösning.

Användning av egna argument i CLI och konfiguration

Om du missbrukade CLI för att skicka egna argument till konfigurationen på följande sätt:

webpack --custom-stuff

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

Du kanske märker att detta inte längre är tillåtet. CLI är strängare nu.

Istället finns det ett gränssnitt för att skicka argument till konfigurationen. Detta bör användas i stället. Framtida verktyg kan förlita sig på detta.

webpack --env.customStuff

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

Se CLI.

require.ensure och AMD require är asynkrona

De här funktionerna är nu alltid asynkrona i stället för att anropa sin callback synkront om chunken redan är inläst.

require.ensure är nu beroende av native Promises. Om du använder require.ensure i en miljö som saknar dem behöver du en polyfill.

Laddarkonfiguration sker via alternativ

Du kan inte längre konfigurera en laddare med en anpassad egenskap i webpack.config.js. Det måste göras via options. Följande konfiguration med egenskapen ts är inte längre giltig med webpack 2:

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

Vad är alternativ?

God fråga. Tja, strängt taget är det 2 möjliga saker; båda sätten att konfigurera en webpack-loader. Klassiskt kallades options för query och var en sträng som kunde läggas till namnet på laddaren. Ungefär som en frågeserie-sträng men faktiskt med större befogenheter:

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

Men det kan också vara ett separat specificerat objekt som levereras tillsammans med en laddare:

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

LoaderOptionsPlugin context

Vissa laddare behöver kontextinformation och läser dem från konfigurationen. Detta måste överföras via loader options på lång sikt. Se dokumentation om laddare för relevanta alternativ.

För att behålla kompatibiliteten med gamla laddare kan den här informationen överföras via plugin:

 plugins: 

debug

Optionen debug växlade laddare till felsökningsläge i webpack 1. Detta måste överföras via laddningsalternativ på lång sikt. Se loader-dokumentationen för relevanta alternativ.

Debugläget för loaders kommer att tas bort i webpack 3 eller senare.

För att behålla kompatibiliteten med gamla laddare kan laddare kopplas om till felsökningsläge via ett insticksmodul:

- debug: true, plugins: 

Kodeuppdelning med ES2015

I webpack 1 kan du använda require.ensure() som en metod för att lazily-ladda delar för din applikation:

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

Specifikationen för ES2015 Loader definierar import() som en metod för att ladda ES2015-moduler dynamiskt vid körning. webpack behandlar import() som en delningspunkt och placerar den begärda modulen i en separat delning. import() tar modulnamnet som argument och returnerar en Promise.

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

Goda nyheter: Fungerande laddning av en chunk kan nu hanteras eftersom de är Promise baserade.

Dynamiska uttryck

Det är möjligt att skicka ett partiellt uttryck till import(). Detta hanteras på samma sätt som uttryck i CommonJS (webpack skapar en kontext med alla möjliga filer).

import() skapar en separat chunk för varje möjlig modul.

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

Blandning av ES2015 med AMD och CommonJS

Som för AMD och CommonJS kan du fritt blanda alla tre modultyperna (även inom samma fil). webpack beter sig på samma sätt som babel och node-eps i det här fallet:

// 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';

Det är viktigt att notera att du vill be Babel att inte analysera dessa modulsymboler så att webpack kan använda dem. Du kan göra detta genom att ställa in följande i dina .babelrc eller babel-loader alternativ.

.babelrc

{ "presets": ]}

Hänvisningar

Ingen anledning att ändra något, men möjligheter

Mallsträngar

webpack stöder nu mallsträngar i uttryck. Detta innebär att du kan börja använda dem i webpack-konstruktioner:

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

Configuration Promise

webpack har nu stöd för att returnera en Promise från konfigurationsfilen. Detta möjliggör asynkron behandling i din konfigurationsfil.

webpack.config.js

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

Avancerad matchning av laddare

webpack har nu stöd för fler saker att matcha på för laddare.

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

Mer CLI-alternativ

Det finns några nya CLI-alternativ som du kan använda:

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

--display-depth visar avståndet till startpunkten för varje modul.

--display-used-exports visar information om vilka exporter som används i en modul.

--display-max-modules ställer in antalet för moduler som visas i utdata (standardvärdet är 15).

-p definierar även process.env.NODE_ENV till "production" nu.

Loaderändringar

Förändringar som endast är relevanta för loaderförfattare.

Cacheable

Loader är nu cacheable som standard. Laddare måste välja bort om de inte är cacheable.

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

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

Komplexa alternativ

webpack 1 har endast stöd för JSON.stringify-kapabla alternativ för laddare.

webpack 2 har nu stöd för alla JS-objekt som laddningsalternativ.