Secțiunile următoare descriu schimbările majore de la webpack 1 la 2.

resolve.root, resolve.fallback, resolve.modulesDirectories

Aceste opțiuni au fost înlocuite cu o singură opțiune resolve.modules. Consultați rezolvarea pentru mai multe utilizări.

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

resolve.extensions

Această opțiune nu mai necesită trecerea unui șir gol. Acest comportament a fost mutat în resolve.enforceExtension. A se vedea rezolvarea pentru mai multe utilizări.

resolve.*

Aici au fost modificate mai multe API-uri. Nu sunt enumerate în detaliu, deoarece nu sunt utilizate în mod obișnuit. Vezi resolving pentru detalii.

module.loaders este acum module.rules

Vechiul sistem de configurare a încărcătoarelor a fost înlocuit de un sistem de reguli mai puternic, care permite configurarea încărcătoarelor și altele. Din motive de compatibilitate, vechea sintaxă module.loaders este încă valabilă și vechile nume sunt analizate. Noile convenții de denumire sunt mai ușor de înțeles și reprezintă un motiv bun pentru a actualiza configurația la utilizarea module.rules.

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

Clanșarea încărcătoarelor

Ca și în webpack 1, încărcătoarele pot fi înlănțuite pentru a trece rezultatele de la încărcător la încărcător. Utilizând opțiunea de configurare rule.use, use poate fi setată la o matrice de încărcătoare. În webpack 1, încărcătoarele erau de obicei înlănțuite cu !. Acest stil este suportat doar folosind opțiunea veche module.loaders.

 module: {- loaders: }] }

Extinderea automată a numelui modulului -loader a fost eliminată

Nu mai este posibilă omiterea extensiei -loader atunci când se face referire la încărcătoare:

 module: { rules: } ] }

Puteți opta în continuare pentru vechiul comportament cu opțiunea de configurare resolveLoader.moduleExtensions, dar acest lucru nu este recomandat.

+ resolveLoader: {+ moduleExtensions: + }

Vezi #2986 pentru motivul din spatele acestei modificări.

json-loader nu mai este necesar

Când nu a fost configurat niciun încărcător pentru un fișier JSON, webpack va încerca automat să încarce fișierul JSON cu opțiunea json-loader.

 module: { rules: }

Am decis să facem acest lucru pentru a aplana diferențele de mediu între webpack, node.js și browserify.

Încărcătoarele din configurare se rezolvă relativ la context

În webpack 1, încărcătoarele configurate se rezolvă relativ la fișierul asociat. Cu toate acestea, în webpack 2, încărcătoarele configurate se rezolvă relativ la opțiunea context.

Aceasta rezolvă unele probleme cu modulele duplicate cauzate de încărcătoare atunci când se utilizează npm link sau când se face referire la module în afara context.

Puteți elimina unele hack-uri pentru a lucra în jurul acestui lucru:

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

module.preLoaders și module.postLoaders au fost eliminate:

 module: {- preLoaders: }

UglifyJsPlugin sourceMap

Opțiunea sourceMap din UglifyJsPlugin este acum implicită la false în loc de true. Acest lucru înseamnă că, dacă utilizați hărți sursă pentru cod minimizat sau doriți numere de linie corecte pentru avertismentele uglifyjs, trebuie să setați sourceMap: true pentru UglifyJsPlugin.

 devtool: "source-map", plugins: 

UglifyJsPlugin warnings

Opțiunea compress.warnings a UglifyJsPlugin este acum implicită la false în loc de true. Acest lucru înseamnă că, dacă doriți să vedeți avertismentele uglifyjs, trebuie să setați compress.warnings la true.

 devtool: "source-map", plugins: 

UglifyJsPlugin minimize loaders

UglifyJsPlugin nu mai comută încărcătoarele în modul minim. Setarea minimize: true trebuie să fie transmisă prin opțiunile încărcătorului pe termen lung. Consultați documentația încărcătorului pentru opțiunile relevante.

Modul de minimizare pentru încărcători va fi eliminat în webpack 3 sau mai târziu.

Pentru a păstra compatibilitatea cu încărcătoarele vechi, încărcătoarele pot fi comutate în modul de minimizare prin intermediul pluginului:

 plugins: 

DedupePlugin a fost eliminat

webpack.optimize.DedupePlugin nu mai este necesar. Eliminați-l din configurație.

BannerPlugin – schimbare de ultimă oră

BannerPlugin nu mai acceptă doi parametri, ci un singur obiect de opțiuni.

 plugins: 

OccurrenceOrderPlugin este acum activat implicit

Pluginul OccurrenceOrderPlugin este acum activat implicit și a fost redenumit (OccurenceOrderPlugin în webpack 1). Astfel, asigurați-vă că eliminați pluginul din configurația dvs.:

 plugins: 

ExtractTextWebpackPlugin – schimbare de întrerupere

ExtractTextPlugin necesită versiunea 2 pentru a funcționa cu webpack 2.

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

Modificările de configurare pentru acest plugin sunt în principal sintactice.

module: { rules: }

new ExtractTextPlugin({options})

plugins: 

Exigențele dinamice complete eșuează acum în mod implicit

O dependență cu doar o expresie (i. e. require(expr)) va crea acum un context gol în loc de contextul directorului complet.

Codul ca acesta ar trebui refactorizat deoarece nu va funcționa cu modulele ES2015. Dacă acest lucru nu este posibil, puteți utiliza ContextReplacementPlugin pentru a îndruma compilatorul spre rezolvarea corectă.

Utilizarea argumentelor personalizate în CLI și în configurare

Dacă ați abuzat de CLI pentru a trece argumente personalizate în configurare, astfel:

webpack --custom-stuff

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

Ați putea observa că acest lucru nu mai este permis. CLI-ul este mai strict acum.

În schimb, există o interfață pentru a trece argumente către configurație. Aceasta ar trebui să fie folosită în schimb. Instrumentele viitoare ar putea să se bazeze pe aceasta.

webpack --env.customStuff

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

Vezi CLI.

require.ensure și AMD require sunt asincrone

Aceste funcții sunt acum întotdeauna asincrone în loc să apeleze sincron la callback-ul lor dacă chunk-ul este deja încărcat.

require.ensureAcum depinde de Promises nativi. Dacă folosiți require.ensure într-un mediu care nu le are, atunci veți avea nevoie de un polyfill.

Configurarea încărcătorului se face prin opțiuni

Nu mai puteți configura un încărcător cu o proprietate personalizată în webpack.config.js. Trebuie să se facă prin intermediul opțiunilor options. Următoarea configurare cu proprietatea ts nu mai este valabilă cu webpack 2:

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

Ce sunt opțiunile?

Bună întrebare. Ei bine, strict vorbind, sunt 2 lucruri posibile; ambele moduri de a configura un încărcător webpack. În mod clasic options se numea query și era un șir de caractere care putea fi atașat la numele încărcătorului. La fel ca un șir de interogare, dar de fapt cu puteri mai mari:

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

Dar poate fi, de asemenea, un obiect specificat separat care este furnizat alături de un încărcător:

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

LoaderOptionsPlugin context

Câteva încărcătoare au nevoie de informații de context și le citesc din configurație. Acestea trebuie să fie transmise prin intermediul opțiunilor încărcătorului pe termen lung. Consultați documentația încărcătorului pentru opțiunile relevante.

Pentru a păstra compatibilitatea cu încărcătoarele vechi, aceste informații pot fi transmise prin plugin:

 plugins: 

debug

Opțiunea debug a comutat încărcătoarele în modul debug în webpack 1. Acest lucru trebuie transmis prin opțiunile încărcătorului pe termen lung. Consultați documentația încărcătorului pentru opțiunile relevante.

Modul de depanare pentru încărcătoare va fi eliminat în webpack 3 sau ulterior.

Pentru a păstra compatibilitatea cu încărcătoarele vechi, încărcătoarele pot fi comutate în modul de depanare prin intermediul unui plugin:

- debug: true, plugins: 

Code Splitting with ES2015

În webpack 1, ați putea folosi require.ensure() ca metodă pentru a încărca leneș bucăți pentru aplicația dumneavoastră:

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

Specificația încărcătorului ES2015 definește import() ca metodă pentru a încărca dinamic modulele ES2015 în timpul execuției. webpack tratează import() ca un punct de divizare și plasează modulul solicitat într-un chunk separat. import() primește ca argument numele modulului și returnează o promisiune.

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

Veste bună: Eșecul de a încărca un chunk poate fi gestionat acum, deoarece acestea se bazează pe Promise.

Expresii dinamice

Este posibil să se treacă o expresie parțială către import(). Aceasta este tratată similar cu expresiile din CommonJS (webpack creează un context cu toate fișierele posibile).

import() creează un chunk separat pentru fiecare modul posibil.

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

Mixarea ES2015 cu AMD și CommonJS

Ca și în cazul AMD și CommonJS puteți amesteca liber toate cele trei tipuri de module (chiar și în cadrul aceluiași fișier). webpack se comportă similar cu babel și node-eps în acest caz:

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

Este important să rețineți că veți dori să îi spuneți lui Babel să nu analizeze aceste simboluri de modul, astfel încât webpack să le poată utiliza. Puteți face acest lucru setând următoarele în opțiunile .babelrc sau babel-loader.babelrc

.babelrc

{ "presets": ]}

Sugestii

Nu este nevoie să schimbați ceva, ci oportunități

Template strings

webpack suportă acum șiruri de șabloane în expresii. Acest lucru înseamnă că puteți începe să le folosiți în construcțiile webpack:

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

Configuration Promise

webpack suportă acum returnarea unui Promise din fișierul de configurare. Acest lucru permite procesarea asincronă în fișierul dvs. de configurare.

webpack.config.js

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

Advanced loader matching

webpack suportă acum mai multe lucruri pe care să se potrivească pentru încărcătoare.

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

Mai multe opțiuni CLI

Există câteva noi opțiuni CLI pe care le puteți folosi:

--define process.env.NODE_ENV="production" Vedeți DefinePlugin.

--display-depth afișează distanța până la punctul de intrare pentru fiecare modul.

--display-used-exports afișează informații despre ce exporturi sunt utilizate într-un modul.

--display-max-modules stabilește numărul pentru modulele afișate în ieșire (valoarea implicită este 15).

-pDe asemenea, definește de la process.env.NODE_ENV la "production" acum.

Modificări ale încărcătorului

Modificări relevante doar pentru autorii încărcătorului.

Cacheable

Careable

Careadrele sunt acum cacheabile în mod implicit. Încărcătoarele trebuie să renunțe dacă nu sunt cacheable.

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

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

Opțiuni complexe

webpack 1 suportă doar opțiunile JSON.stringify-abile pentru încărcătoare.

webpack 2 suportă acum orice obiect JS ca opțiuni pentru încărcătoare.

.