De følgende afsnit beskriver de vigtigste ændringer fra webpack 1 til 2.

resolve.root, resolve.fallback, resolve.modulesDirectories

Disse indstillinger blev erstattet af en enkelt indstilling resolve.modules. Se resolving for mere brug.

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

resolve.extensions

Denne indstilling kræver ikke længere, at der overføres en tom streng. Denne adfærd blev flyttet til resolve.enforceExtension. Se resolving for mere brug.

resolve.*

Flere API’er blev ændret her. Ikke anført i detaljer, da det ikke er almindeligt anvendt. Se resolving for nærmere oplysninger.

module.loaders er nu module.rules

Den gamle loaderkonfiguration blev afløst af et mere kraftfuldt regelsystem, som giver mulighed for konfiguration af loadere og meget mere. Af kompatibilitetshensyn er den gamle module.loaders-syntaks stadig gyldig, og de gamle navne analyseres. De nye navnekonventioner er lettere at forstå og er en god grund til at opgradere konfigurationen til at bruge module.rules.

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

Kædning af loaderne

Som i webpack 1 kan loaderne kædes sammen for at videregive resultater fra loader til loader. Ved hjælp af konfigurationsindstillingen rule.use kan use indstilles til et array af loadere. I webpack 1 blev loadere almindeligvis kædet sammen med !. Denne stil understøttes kun ved hjælp af den gamle indstilling module.loaders.

 module: {- loaders: }] }

Automatisk -loader modulnavneudvidelse fjernet

Det er ikke længere muligt at udelade -loader-udvidelsen, når der henvises til loadere:

 module: { rules: } ] }

Du kan stadig vælge den gamle adfærd med konfigurationsindstillingen resolveLoader.moduleExtensions, men det anbefales ikke.

+ resolveLoader: {+ moduleExtensions: + }

Se #2986 for årsagen til denne ændring.

json-loader er ikke længere påkrævet

Når der ikke er blevet konfigureret nogen loader for en JSON-fil, vil webpack automatisk forsøge at indlæse JSON-filen med json-loader.

 module: { rules: }

Vi besluttede at gøre dette for at udjævne miljøforskelle mellem webpack, node.js og browserify.

Loaderne i konfigurationen opløses relativt til konteksten

I webpack 1 opløses konfigurerede loaders relativt til den matchede fil. Men i webpack 2 opløser konfigurerede loaders relativt til context-indstillingen.

Dette løser nogle problemer med dublerede moduler forårsaget af loaders, når der bruges npm link eller refereres til moduler uden for context.

Du kan fjerne nogle hacks for at omgå dette:

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

module.preLoaders og module.postLoaders blev fjernet:

 module: {- preLoaders: }

UglifyJsPlugin sourceMap

Den sourceMap indstilling i UglifyJsPlugin er nu standardiseret til false i stedet for true. Det betyder, at hvis du bruger kildekort til minimeret kode eller ønsker korrekte linjenumre for uglifyjs-advarsler, skal du indstille sourceMap: true for UglifyJsPlugin.

 devtool: "source-map", plugins: 

UglifyJsPlugin warnings

Den compress.warnings indstilling i UglifyJsPlugin har nu som standardindstilling false i stedet for true. Det betyder, at hvis du vil se uglifyjs-advarsler, skal du indstille compress.warnings til true.

 devtool: "source-map", plugins: 

UglifyJsPlugin minimize loaders

UglifyJsPlugin skifter ikke længere loaders til minimize-tilstand. Indstillingen minimize: true skal overføres via loaderindstillinger på lang sigt. Se loader-dokumentationen for relevante indstillinger.

Minimize-tilstand for loaders vil blive fjernet i webpack 3 eller senere.

For at bevare kompatibiliteten med gamle loaders kan loaders skiftes til minimize-tilstand via plugin:

 plugins: 

DedupePlugin er blevet fjernet

webpack.optimize.DedupePlugin er ikke længere nødvendigt. Fjern det fra din konfiguration.

BannerPlugin – brydende ændring

BannerPlugin accepterer ikke længere to parametre, men et enkelt optionsobjekt.

 plugins: 

OccurrenceOrderPlugin er nu aktiveret som standard

OccurrenceOrderPlugin er nu aktiveret som standard og er blevet omdøbt (OccurenceOrderPlugin i webpack 1). Sørg derfor for at fjerne plugin’et fra din konfiguration:

 plugins: 

ExtractTextWebpackPlugin – breaking change

ExtractTextPlugin kræver version 2 for at fungere med webpack 2.

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

Konfigurationsændringerne for dette plugin er hovedsageligt syntaktiske.

module: { rules: }

new ExtractTextPlugin({options})

plugins: 

Fuldt dynamiske krav fejler nu som standard

En afhængighed med kun et udtryk (dvs. require(expr)) vil nu oprette en tom kontekst i stedet for konteksten for den komplette mappe.

Kode som denne bør refaktoriseres, da den ikke vil fungere med ES2015-moduler. Hvis dette ikke er muligt, kan du bruge ContextReplacementPlugin til at give compileren et hint om den korrekte opløsning.

Brug af brugerdefinerede argumenter i CLI og konfiguration

Hvis du misbrugte CLI’en til at videregive brugerdefinerede argumenter til konfigurationen på følgende måde:

webpack --custom-stuff

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

Du vil måske bemærke, at dette ikke længere er tilladt. CLI’en er mere streng nu.

I stedet er der en grænseflade til at videregive argumenter til konfigurationen. Dette bør bruges i stedet. Fremtidige værktøjer kan være afhængige af dette.

webpack --env.customStuff

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

Se CLI.

require.ensure og AMD require er asynkrone

Disse funktioner er nu altid asynkrone i stedet for at kalde deres callback synkront, hvis chunken allerede er indlæst.

require.ensure er nu afhængig af native Promises. Hvis du bruger require.ensure i et miljø, der ikke har dem, skal du bruge en polyfill.

Loaderkonfiguration sker via indstillinger

Du kan ikke længere konfigurere en loader med en brugerdefineret egenskab i webpack.config.js. Det skal gøres gennem options. Følgende konfiguration med ts-egenskaben er ikke længere gyldig med webpack 2:

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

Hvad er indstillinger?

Godt spørgsmål. Nå, strengt taget er det 2 mulige ting; begge måder at konfigurere en webpack-loader på. Klassisk blev options kaldt query og var en streng, som kunne tilføjes til navnet på loaderen. Meget som en forespørgselsstreng, men faktisk med større beføjelser:

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

Men det kan også være et separat angivet objekt, der leveres sammen med en loader:

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

LoaderOptionsPlugin context

Nogle loadere har brug for kontekstoplysninger og læser dem fra konfigurationen. Dette skal overføres via loader-optioner i den langsigtede. Se loader-dokumentationen for relevante indstillinger.

For at bevare kompatibiliteten med gamle loadere kan disse oplysninger overføres via plugin:

 plugins: 

debug

Den debug indstilling skiftede loadere til debug-tilstand i webpack 1. Dette skal videregives via loaderindstillinger i langsigtet. Se loader-dokumentationen for relevante indstillinger.

Debug-tilstand for loadere vil blive fjernet i webpack 3 eller senere.

For at bevare kompatibiliteten med gamle loaders kan loaders skiftes til debug-tilstand via et plugin:

- debug: true, plugins: 

Kodeopdeling med ES2015

I webpack 1 kunne du bruge require.ensure() som en metode til at lazily-loade chunks til din applikation:

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

Specifikationen for ES2015 Loader definerer import() som en metode til at indlæse ES2015-moduler dynamisk på køretid. webpack behandler import() som et splitpunkt og placerer det ønskede modul i en separat chunk. import() tager modulnavnet som argument og returnerer en Promise.

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

Gode nyheder: Manglende indlæsning af en chunk kan nu håndteres, fordi de er Promise-baserede.

Dynamiske udtryk

Det er muligt at videregive et delvist udtryk til import(). Dette håndteres på samme måde som udtryk i CommonJS (webpack opretter en kontekst med alle mulige filer).

import() opretter en separat chunk for hvert muligt 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

Mix af ES2015 med AMD og CommonJS

Som for AMD og CommonJS kan du frit blande alle tre modultyper (selv inden for samme fil). webpack opfører sig på samme måde som babel og node-eps i dette tilfælde:

// 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 er vigtigt at bemærke, at du skal fortælle Babel, at han ikke skal parse disse modulsymboler, så webpack kan bruge dem. Det kan du gøre ved at indstille følgende i dine .babelrc eller babel-loader indstillinger.

.babelrc

{ "presets": ]}

Hinvisninger

Ingen grund til at ændre noget, men muligheder

Skabelonstrenge

webpack understøtter nu skabelonstrenge i udtryk. Det betyder, at du kan begynde at bruge dem i webpack-konstruktioner:

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

Configuration Promise

webpack understøtter nu returnering af en Promise fra konfigurationsfilen. Dette giver mulighed for asynkron behandling i din konfigurationsfil.

webpack.config.js

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

Advanced loader matching

webpack understøtter nu flere ting at matche på for loaders.

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

Mere CLI-indstillinger

Der er nogle nye CLI-indstillinger, som du kan bruge:

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

--display-depth viser afstanden til indgangspunktet for hvert modul.

--display-used-exports viser oplysninger om, hvilke eksportvarer der anvendes i et modul.

--display-max-modules indstiller antallet for moduler, der vises i output (standardindstillingen er 15).

-p definerer også process.env.NODE_ENV til "production" nu.

Loaderændringer

Ændringer kun relevante for loaderforfattere.

Cacheable

Loaderne er nu cacheable som standard. Loaderne skal fravælge det, hvis de ikke er cacheable.

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

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

Komplekse indstillinger

webpack 1 understøtter kun JSON.stringify-able indstillinger for loaderne.

webpack 2 understøtter nu ethvert JS-objekt som loaderindstillinger.