De volgende secties beschrijven de belangrijkste wijzigingen van webpack 1 naar 2.

resolve.root, resolve.fallback, resolve.modulesDirectories

Deze opties werden vervangen door een enkele optie resolve.modules. Zie resolving voor meer gebruik.

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

resolve.extensions

Voor deze optie hoeft niet langer een lege string te worden doorgegeven. Dit gedrag is verplaatst naar resolve.enforceExtension. Zie resolving voor meer gebruik.

resolve.*

Verschillende APIs zijn hier veranderd. Niet in detail vermeld omdat het niet vaak gebruikt wordt. Zie resolving voor details.

module.loaders is nu module.rules

De oude loader-configuratie werd vervangen door een krachtiger regelsysteem, dat configuratie van loaders en meer mogelijk maakt. Om compatibiliteitsredenen is de oude module.loaders syntax nog steeds geldig en worden de oude namen geparseerd. De nieuwe naamgevingsconventies zijn eenvoudiger te begrijpen en zijn een goede reden om de configuratie te upgraden naar het gebruik van module.rules.

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

Chaining loaders

Net als in webpack 1 kunnen loaders worden geketend om resultaten van loader naar loader door te geven. Met behulp van de configuratieoptie rule.use kan use worden ingesteld op een array van loaders. In webpack 1, werden loaders gewoonlijk geketend met !. Deze stijl wordt alleen ondersteund met de legacy optie module.loaders.

 module: {- loaders: }] }

Automatische -loader module naam extensie verwijderd

Het is niet meer mogelijk om de -loader extensie weg te laten bij het verwijzen naar loaders:

 module: { rules: } ] }

U kunt nog steeds kiezen voor het oude gedrag met de resolveLoader.moduleExtensions configuratie optie, maar dit wordt niet aangeraden.

+ resolveLoader: {+ moduleExtensions: + }

Zie #2986 voor de reden achter deze verandering.

json-loader is niet meer vereist

Wanneer er geen loader is geconfigureerd voor een JSON-bestand, zal webpack automatisch proberen het JSON-bestand te laden met de json-loader.

 module: { rules: }

We hebben besloten dit te doen om de verschillen in omgeving tussen webpack, node.js en browserify glad te strijken.

Loaders in configuratie resolven relatief aan context

In webpack 1, resolven geconfigureerde loaders relatief aan het gematchte bestand. In webpack 2 worden geconfigureerde loaders echter relatief aan de context optie opgelost.

Dit lost enkele problemen op met dubbele modules veroorzaakt door loaders bij gebruik van npm link of verwijzingen naar modules buiten de context.

U kunt enkele hacks verwijderen om hier omheen te werken:

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

module.preLoaders en module.postLoaders zijn verwijderd:

 module: {- preLoaders: }

UglifyJsPlugin sourceMap

De sourceMap optie van de UglifyJsPlugin staat nu standaard op false in plaats van true. Dit betekent dat als u source maps gebruikt voor geminimaliseerde code of correcte regelnummers wilt voor uglifyjs waarschuwingen, u sourceMap: true moet instellen voor UglifyJsPlugin.

 devtool: "source-map", plugins: 

UglifyJsPlugin waarschuwingen

De compress.warnings optie van de UglifyJsPlugin staat nu standaard op false in plaats van true. Dit betekent dat als u uglifyjs waarschuwingen wilt zien, u compress.warnings op true moet zetten.

 devtool: "source-map", plugins: 

UglifyJsPlugin minimaliseer laders

UglifyJsPlugin schakelt laders niet langer in minimaliseer modus. De instelling minimize: true moet worden doorgegeven via loader-opties op de lange termijn. Zie loader-documentatie voor relevante opties.

De minimalize-modus voor loaders wordt verwijderd in webpack 3 of later.

Om compatibiliteit met oude loaders te behouden, kunnen loaders naar de minimalize-modus worden geschakeld via een plugin:

 plugins: 

DedupePlugin is verwijderd.

webpack.optimize.DedupePlugin is niet meer nodig. Verwijder het uit uw configuratie.

BannerPlugin – breaking change

BannerPlugin accepteert niet langer twee parameters, maar een enkel optie-object.

 plugins: 

OccurrenceOrderPlugin is nu standaard ingeschakeld

De OccurrenceOrderPlugin is nu standaard ingeschakeld en heeft een andere naam gekregen (OccurenceOrderPlugin in webpack 1). Zorg er dus voor dat u de plugin uit uw configuratie verwijdert:

 plugins: 

ExtractTextWebpackPlugin – breaking change

ExtractTextPlugin vereist versie 2 om met webpack 2 te kunnen werken.

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

De configuratiewijzigingen voor deze plugin zijn voornamelijk syntactisch van aard.

module: { rules: }

new ExtractTextPlugin({options})

plugins: 

Full dynamic requires falen nu standaard

Een dependency met alleen een expressie (dus require(expr)) maakt nu een lege context aan in plaats van de context van de volledige directory.

Code als deze moet worden ge-refactored omdat het niet werkt met ES2015-modules. Als dit niet mogelijk is, kunt u de ContextReplacementPlugin gebruiken om de compiler te hinten in de richting van de juiste resolving.

Gebruik van aangepaste argumenten in CLI en configuratie

Als u de CLI misbruikte om aangepaste argumenten door te geven aan de configuratie, zoals dit:

webpack --custom-stuff

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

U zult merken dat dit niet meer is toegestaan. De CLI is nu strenger.

In plaats daarvan is er een interface voor het doorgeven van argumenten aan de configuratie. Deze moet in plaats daarvan worden gebruikt. Toekomstige hulpprogramma’s kunnen hierop vertrouwen.

webpack --env.customStuff

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

Zie CLI.

require.ensure en AMD require zijn asynchroon

Deze functies zijn nu altijd asynchroon in plaats van hun callback synchroon aan te roepen als de chunk al is geladen.

require.ensure is nu afhankelijk van native Promises. Als u require.ensure gebruikt in een omgeving waar deze niet aanwezig zijn, dan heeft u een polyfill nodig.

Loader configuratie gaat via opties

U kunt niet langer een loader configureren met een aangepaste eigenschap in de webpack.config.js. Dit moet worden gedaan via de options. De volgende configuratie met de ts eigenschap is niet langer geldig met webpack 2:

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

Wat zijn opties?

Goede vraag. Nou, strikt genomen zijn het 2 mogelijke dingen; beide manieren om een webpack loader te configureren. Klassiek heette options query en was een string die kon worden toegevoegd aan de naam van de loader. Net als een querystring, maar dan met grotere bevoegdheden:

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

Maar het kan ook een apart gespecificeerd object zijn dat samen met een loader wordt geleverd:

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

LoaderOptionsPlugin context

Sommige loaders hebben contextinformatie nodig en lezen die uit de configuratie. Dit moet worden doorgegeven via loader opties in de lange termijn. Zie loader documentatie voor relevante opties.

Om compatibiliteit met oude loaders te behouden, kan deze informatie via plugin worden doorgegeven:

 plugins: 

debug

De debug optie schakelde loaders over naar debug modus in webpack 1. Dit moet worden doorgegeven via loader opties op lange termijn. Zie loader documentatie voor relevante opties.

De debug modus voor loaders zal worden verwijderd in webpack 3 of later.

Om compatibiliteit met oude loaders te behouden, kunnen loaders via een plugin in debug-modus worden gezet:

- debug: true, plugins: 

Code Splitting with ES2015

In webpack 1 kon u require.ensure() gebruiken als methode om chunks voor uw applicatie lazily te laden:

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

De ES2015 Loader spec definieert import() als methode om ES2015 Modules dynamisch te laden op runtime. webpack behandelt import() als een split-point en plaatst de gevraagde module in een aparte chunk. import() neemt de module naam als argument en retourneert een Promise.

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

Goed nieuws: Het mislukken van het laden van een chunk kan nu worden afgehandeld omdat ze Promise gebaseerd zijn.

Dynamische expressies

Het is mogelijk om een gedeeltelijke expressie door te geven aan import(). Dit wordt op dezelfde manier afgehandeld als expressies in CommonJS (webpack maakt een context met alle mogelijke bestanden).

import()maakt een aparte chunk voor elke mogelijke module.

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

Mixen van ES2015 met AMD en CommonJS

Zoals bij AMD en CommonJS kunt u alle drie de moduletypes vrijelijk mixen (zelfs binnen hetzelfde bestand). webpack gedraagt zich in dit geval vergelijkbaar met babel en node-eps:

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

Het is belangrijk op te merken dat u Babel zult willen vertellen deze module-symbolen niet te parsen, zodat webpack ze kan gebruiken. U kunt dit doen door het volgende in te stellen in uw .babelrc of babel-loader opties.

.babelrc

{ "presets": ]}

Hints

Niet nodig om iets te veranderen, maar mogelijkheden

Template strings

webpack ondersteunt nu template strings in expressies. Dit betekent dat u ze kunt gaan gebruiken in webpack constructies:

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

Configuratiebelofte

webpack ondersteunt nu het retourneren van een Promise uit het configuratiebestand. Dit maakt async verwerking in uw configuratiebestand mogelijk.

webpack.config.js

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

Geavanceerde loader matching

webpack ondersteunt nu meer dingen om op te matchen voor loaders.

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

Meer CLI opties

Er zijn enkele nieuwe CLI opties die u kunt gebruiken:

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

--display-depth toont de afstand tot het ingangspunt voor elke module.

--display-used-exports geeft informatie weer over welke exports in een module worden gebruikt.

--display-max-modules stelt het aantal modules in dat in de uitvoer wordt weergegeven (standaard ingesteld op 15).

-p definieert nu ook process.env.NODE_ENV tot "production".

Loader wijzigingen

Veranderingen alleen relevant voor loader auteurs.

Cacheable

Loaders zijn nu standaard cacheable. Loaders moeten zich afmelden als ze niet cacheable zijn.

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

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

Complexe opties

webpack 1 ondersteunt alleen JSON.stringify-able opties voor loaders.

webpack 2 ondersteunt nu elk JS object als loader opties.