Poniższe sekcje opisują główne zmiany z webpacka 1 do 2.

resolve.root, resolve.fallback, resolve.modulesDirectories

Te opcje zostały zastąpione pojedynczą opcją resolve.modules. Zobacz resolving dla więcej użycia.

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

resolve.extensions

Ta opcja nie wymaga już przekazywania pustego łańcucha. To zachowanie zostało przeniesione do resolve.enforceExtension. Zobacz resolving dla więcej użycia.

resolve.*

Kilka API zostało tutaj zmienionych. Nie wymienione szczegółowo, ponieważ nie są one powszechnie używane. Zobacz resolving po szczegóły.

module.loaders to teraz module.rules

Stara konfiguracja loaderów została zastąpiona przez potężniejszy system reguł, który pozwala na konfigurację loaderów i nie tylko. Ze względu na kompatybilność, stara składnia module.loaders jest nadal ważna i stare nazwy są parsowane. Nowe konwencje nazewnictwa są łatwiejsze do zrozumienia i są dobrym powodem, aby zaktualizować konfigurację do używania module.rules.

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

Łańcuchowanie loaderów

Podobnie jak w webpacku 1, loadery można łączyć w łańcuchy, aby przekazywać wyniki z loadera do loadera. Używając opcji konfiguracyjnej rule.use, use może być ustawione na tablicę loaderów. W webpacku 1, loadery były powszechnie łączone w łańcuchy za pomocą !. Ten styl jest obsługiwany tylko przy użyciu opcji legacy module.loaders.

 module: {- loaders: }] }

Automatyczne usuwanie rozszerzenia nazwy modułu -loader

Nie jest już możliwe pominięcie rozszerzenia -loader podczas odwoływania się do loaderów:

 module: { rules: } ] }

Można jeszcze zdecydować się na stare zachowanie przy użyciu opcji konfiguracyjnej resolveLoader.moduleExtensions, ale nie jest to zalecane.

+ resolveLoader: {+ moduleExtensions: + }

Zobacz #2986 dla powodu tej zmiany.

json-loader nie jest już wymagany

Gdy żaden loader nie został skonfigurowany dla pliku JSON, webpack będzie automatycznie próbował załadować plik JSON za pomocą opcji json-loader.

 module: { rules: }

Postanowiliśmy to zrobić, aby zniwelować różnice środowiskowe między webpackiem, node.js i browserify.

Loadery w konfiguracji rozwiązują się względem kontekstu

W webpacku 1, skonfigurowane loadery rozwiązują się względem dopasowanego pliku. Jednak w webpack 2, skonfigurowane loadery rozwiązują się względem opcji context.

To rozwiązuje niektóre problemy z duplikatami modułów spowodowanymi przez loadery podczas używania npm link lub odwoływania się do modułów poza context.

Możesz usunąć kilka hacków, aby obejść to:

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

module.preLoaders i module.postLoaders zostały usunięte:

 module: {- preLoaders: }

UglifyJsPlugin sourceMap

Opcja sourceMap modułu UglifyJsPlugin domyślnie ustawia się teraz na false zamiast true. Oznacza to, że jeśli używasz map źródłowych dla zminimalizowanego kodu lub chcesz mieć poprawne numery linii dla ostrzeżeń uglifyjs, musisz ustawić sourceMap: true dla UglifyJsPlugin.

 devtool: "source-map", plugins: 

UglifyJsPlugin warnings

The compress.warnings option of the UglifyJsPlugin now defaults to false instead of true. Oznacza to, że jeśli chcesz zobaczyć ostrzeżenia uglifyjs, musisz ustawić compress.warnings na true.

 devtool: "source-map", plugins: 

UglifyJsPlugin minimalizuj loadery

UglifyJsPlugin nie przełącza już loaderów w tryb minimalizacji. Ustawienie minimize: true musi być przekazane przez opcje programu ładującego w długim okresie czasu. Zobacz dokumentację loadera dla odpowiednich opcji.

Tryb minimalizacji dla loaderów zostanie usunięty w webpacku 3 lub nowszym.

Aby zachować kompatybilność ze starymi loaderami, loadery mogą być przełączane do trybu minimalizacji poprzez plugin:

 plugins: 

DedupePlugin został usunięty

webpack.optimize.DedupePlugin nie jest już potrzebny. Usuń go ze swojej konfiguracji.

BannerPlugin – zmiana łamiąca

BannerPlugin nie akceptuje już dwóch parametrów, ale pojedynczy obiekt opcji.

 plugins: 

OccurrenceOrderPlugin jest teraz domyślnie włączony

Wtyczka OccurrenceOrderPlugin jest teraz domyślnie włączona i została zmieniona jej nazwa (OccurenceOrderPlugin w webpack 1). Dlatego upewnij się, że usuniesz wtyczkę ze swojej konfiguracji:

 plugins: 

ExtractTextWebpackPlugin – zmiana łamiąca

ExtractTextPlugin wymaga wersji 2 do pracy z webpackiem 2.

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

Zmiany konfiguracyjne dla tej wtyczki są głównie składniowe.

module: { rules: }

new ExtractTextPlugin({options})

plugins: 

Full dynamic requires now fail by default

Zależność zawierająca tylko wyrażenie (np. require(expr)) będzie teraz tworzyć pusty kontekst zamiast kontekstu pełnego katalogu.

Kod taki jak ten powinien być refaktoryzowany, ponieważ nie będzie działał z modułami ES2015. Jeśli nie jest to możliwe, możesz użyć ContextReplacementPlugin, aby podpowiedzieć kompilatorowi w kierunku poprawnego rozwiązywania.

Używanie niestandardowych argumentów w CLI i konfiguracji

Jeśli nadużyłeś CLI, aby przekazać niestandardowe argumenty do konfiguracji, takie jak:

webpack --custom-stuff

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

Możesz zauważyć, że nie jest to już dozwolone. CLI jest teraz bardziej rygorystyczne.

Zamiast tego istnieje interfejs do przekazywania argumentów do konfiguracji. To powinno być używane zamiast tego. Przyszłe narzędzia mogą na tym polegać.

webpack --env.customStuff

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

Zobacz CLI.

require.ensure i AMD require są asynchroniczne

Te funkcje są teraz zawsze asynchroniczne zamiast wywoływać ich wywołania zwrotne synchronicznie, jeśli chunk jest już załadowany.

require.ensure teraz zależy od natywnych Promises. Jeśli używasz require.ensure w środowisku, w którym ich brakuje, będziesz potrzebował polyfill.

Konfiguracja loadera odbywa się poprzez opcje

Nie można już skonfigurować loadera za pomocą niestandardowej właściwości w webpack.config.js. Musi to być zrobione przez options. Następująca konfiguracja z właściwością ts nie jest już ważna z webpackiem 2:

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

Co to są opcje?

Dobre pytanie. Cóż, ściśle mówiąc są to 2 możliwe rzeczy; oba sposoby konfigurowania programu ładującego webpack. Klasycznie options nazywało się query i było ciągiem znaków, który mógł być dołączony do nazwy programu ładującego. Podobnie jak ciąg zapytania, ale w rzeczywistości z większymi uprawnieniami:

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

Ale może to być również oddzielnie określony obiekt, który jest dostarczany wraz z loaderem:

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

LoaderOptionsPlugin context

Niektóre loadery potrzebują informacji o kontekście i odczytują je z konfiguracji. To musi być przekazane przez opcje loadera w długoterminowych. Zobacz dokumentację loadera dla odpowiednich opcji.

Aby zachować kompatybilność ze starymi loaderami, te informacje mogą być przekazywane przez plugin:

 plugins: 

debug

Opcja debug przełączała loadery do trybu debug w webpacku 1. To musi być przekazane przez opcje loadera w długim czasie. Zobacz dokumentację loadera dla odpowiednich opcji.

Tryb debugowania dla loaderów zostanie usunięty w webpacku 3 lub nowszym.

Aby zachować kompatybilność ze starymi loaderami, loadery mogą być przełączone w tryb debugowania poprzez plugin:

- debug: true, plugins: 

Dzielenie kodu z ES2015

W webpacku 1, mogłeś użyć require.ensure() jako metody do leniwego ładowania fragmentów dla twojej aplikacji:

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

Specyfikacja ES2015 Loader definiuje import() jako metodę do dynamicznego ładowania modułów ES2015 w czasie wykonywania. webpack traktuje import() jako split-point i umieszcza żądany moduł w osobnym chunk. import() przyjmuje nazwę modułu jako argument i zwraca Promise.

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

Dobra wiadomość: Nieudane ładowanie chunk może być teraz obsługiwane, ponieważ są one oparte na Promise.

Wyrażenia dynamiczne

Możliwe jest przekazanie częściowego wyrażenia do import(). Jest to obsługiwane podobnie do wyrażeń w CommonJS (webpack tworzy kontekst ze wszystkimi możliwymi plikami).

import()tworzy osobny chunk dla każdego możliwego modułu.

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

Mieszanie ES2015 z AMD i CommonJS

Tak jak w przypadku AMD i CommonJS można dowolnie mieszać wszystkie trzy typy modułów (nawet w obrębie tego samego pliku). webpack zachowuje się podobnie do babel i node-eps w tym przypadku:

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

Ważne jest, aby zauważyć, że będziesz chciał powiedzieć Babelowi, aby nie parsował tych symboli modułów, aby webpack mógł ich używać. Możesz to zrobić ustawiając następujące opcje w swoich .babelrc lub babel-loader.

.babelrc

{ "presets": ]}

Wskazówki

Nie ma potrzeby zmieniać czegoś, ale są możliwości

Ciągi szablonów

webpack obsługuje teraz ciągi szablonów w wyrażeniach. Oznacza to, że możesz zacząć używać ich w konstrukcjach webpack:

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

Configuration Promise

webpack obsługuje teraz zwracanie Promise z pliku konfiguracyjnego. Pozwala to na przetwarzanie asynchroniczne w twoim pliku konfiguracyjnym.

webpack.config.js

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

Zaawansowane dopasowywanie loaderów

webpack obsługuje teraz więcej rzeczy do dopasowania dla loaderów.

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

Więcej opcji CLI

Do użycia jest kilka nowych opcji CLI:

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

--display-depth wyświetla odległość do punktu wejścia dla każdego modułu.

--display-used-exports wyświetla informacje o tym, które eksporty są używane w module.

--display-max-modules ustawia liczbę modułów wyświetlanych na wyjściu (domyślnie 15).

-p definiuje również process.env.NODE_ENV do "production" teraz.

Zmiany loadera

Zmiany istotne tylko dla autorów loaderów.

Cacheable

Loadery są teraz domyślnie buforowane. Loadery muszą zrezygnować, jeśli nie są cacheable.

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

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

Kompleksowe opcje

webpack 1 obsługuje tylko JSON.stringify-able options dla loaderów.

webpack 2 obsługuje teraz dowolny obiekt JS jako opcje loadera.

Zmiany istotne tylko dla autorów loaderów.