Les sections suivantes décrivent les principaux changements de webpack 1 à 2.

resolve.root, resolve.fallback, resolve.modulesDirectories

Ces options ont été remplacées par une seule option resolve.modules. Voir resolving pour plus d’utilisation.

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

resolve.extensions

Cette option ne nécessite plus de passer une chaîne vide. Ce comportement a été déplacé vers resolve.enforceExtension. Voir resolving pour plus d’utilisation.

resolve.*

Plusieurs API ont été modifiées ici. Pas listé en détail car ce n’est pas couramment utilisé. Voir resolving pour plus de détails.

module.loaders est maintenant module.rules

L’ancienne configuration des chargeurs a été remplacée par un système de règles plus puissant, qui permet la configuration des chargeurs et plus encore. Pour des raisons de compatibilité, l’ancienne syntaxe module.loaders est toujours valide et les anciens noms sont analysés. Les nouvelles conventions de nommage sont plus faciles à comprendre et constituent une bonne raison de mettre à niveau la configuration pour utiliser module.rules.

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

Chaînage de chargeurs

Comme dans webpack 1, les chargeurs peuvent être chaînés pour passer les résultats d’un chargeur à l’autre. En utilisant l’option de configuration rule.use, use peut être défini comme un tableau de loaders. Dans webpack 1, les loaders étaient couramment enchaînés avec !. Ce style n’est pris en charge qu’en utilisant l’option héritée module.loaders.

 module: {- loaders: }] }

Suppression de l’extension automatique du nom du module du chargeur

Il n’est plus possible d’omettre l’extension -loader lors du référencement des chargeurs :

 module: { rules: } ] }

Vous pouvez toujours opter pour l’ancien comportement avec l’option de configuration resolveLoader.moduleExtensions, mais ce n’est pas recommandé.

+ resolveLoader: {+ moduleExtensions: + }

Voir #2986 pour la raison derrière ce changement.

json-loader n’est plus nécessaire

Lorsqu’aucun chargeur n’a été configuré pour un fichier JSON, webpack essaiera automatiquement de charger le fichier JSON avec le json-loader.

 module: { rules: }

Nous avons décidé de faire cela afin d’aplanir les différences d’environnement entre webpack, node.js et browserify.

Les chargeurs dans la configuration résolvent par rapport au contexte

Dans webpack 1, les chargeurs configurés résolvent par rapport au fichier apparié. Cependant, dans webpack 2, les chargeurs configurés résolvent relativement à l’option context.

Cela résout certains problèmes de modules dupliqués causés par les chargeurs lors de l’utilisation de npm link ou du référencement de modules en dehors du context.

Vous pouvez supprimer certains hacks pour contourner cela :

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

module.preLoaders et module.postLoaders ont été supprimés :

 module: {- preLoaders: }

UglifyJsPlugin sourceMap

L’option sourceMap de la UglifyJsPlugin prend maintenant par défaut false au lieu de true. Cela signifie que si vous utilisez des cartes de source pour du code minimisé ou si vous voulez des numéros de ligne corrects pour les avertissements uglifyjs, vous devez définir sourceMap: true pour UglifyJsPlugin.

 devtool: "source-map", plugins: 

UglifyJsPlugin warnings

L’option compress.warnings de la UglifyJsPlugin prend maintenant par défaut false au lieu de true. Cela signifie que si vous voulez voir les avertissements d’uglifyjs, vous devez définir compress.warnings à true.

 devtool: "source-map", plugins: 

UglifyJsPlugin minimiser les chargeurs

UglifyJsPlugin ne commute plus les chargeurs en mode minimisation. Le paramètre minimize: true doit être passé via les options du chargeur à long terme. Voir la documentation du chargeur pour les options pertinentes.

Le mode minimisé pour les chargeurs sera supprimé dans webpack 3 ou plus tard.

Pour garder la compatibilité avec les anciens chargeurs, les chargeurs peuvent être basculés en mode minimisé via le plugin:

 plugins: 

DedupePlugin a été supprimé

webpack.optimize.DedupePlugin n’est plus nécessaire. Supprimez-le de votre configuration.

BannerPlugin – changement de rupture

BannerPlugin n’accepte plus deux paramètres, mais un seul objet d’options.

 plugins: 

OccurrenceOrderPlugin est maintenant activé par défaut

Le OccurrenceOrderPlugin est maintenant activé par défaut et a été renommé (OccurenceOrderPlugin dans webpack 1). Ainsi, assurez-vous de supprimer le plugin de votre configuration :

 plugins: 

ExtractTextWebpackPlugin – changement de rupture

ExtractTextPlugin nécessite la version 2 pour fonctionner avec webpack 2.

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

Les changements de configuration pour ce plugin sont principalement syntaxiques.

module: { rules: }

new ExtractTextPlugin({options})

plugins: 

Les exigences dynamiques complètes échouent maintenant par défaut

Une dépendance avec seulement une expression (i. e. require(expr)) créera maintenant un contexte vide au lieu du contexte du répertoire complet.

Un code comme celui-ci devrait être refactorisé car il ne fonctionnera pas avec les modules ES2015. Si ce n’est pas possible, vous pouvez utiliser le ContextReplacementPlugin pour orienter le compilateur vers la résolution correcte.

Utilisation d’arguments personnalisés dans le CLI et la configuration

Si vous avez abusé du CLI pour passer des arguments personnalisés à la configuration comme suit :

webpack --custom-stuff

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

Vous pouvez remarquer que cela n’est plus autorisé. Le CLI est plus strict maintenant.

A la place, il existe une interface pour passer des arguments à la configuration. Cela devrait être utilisé à la place. Les outils futurs peuvent s’appuyer sur cela.

webpack --env.customStuff

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

Voir CLI.

require.ensure et AMD require sont asynchrones

Ces fonctions sont maintenant toujours asynchrones au lieu d’appeler leur callback de manière synchrone si le chunk est déjà chargé.

require.ensure dépend maintenant des Promises natives. Si vous utilisez require.ensure dans un environnement qui en est dépourvu, alors vous aurez besoin d’un polyfill.

La configuration du chargeur se fait via les options

Vous ne pouvez plus configurer un chargeur avec une propriété personnalisée dans le webpack.config.js. Cela doit être fait par le biais des options. La configuration suivante avec la propriété ts n’est plus valide avec webpack 2:

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

Que sont les options ?

Bonne question. Eh bien, à proprement parler, ce sont 2 choses possibles ; les deux façons de configurer un chargeur webpack. Classiquement, options était appelé query et était une chaîne qui pouvait être ajoutée au nom du chargeur. Un peu comme une chaîne de requête mais en fait avec de plus grands pouvoirs:

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

Mais cela peut aussi être un objet spécifié séparément qui est fourni aux côtés d’un chargeur:

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

LoaderOptionsPlugin context

Certains chargeurs ont besoin d’informations de contexte et les lisent depuis la configuration. Cela doit être passé via les options du chargeur dans le long terme. Voir la documentation du chargeur pour les options pertinentes.

Pour garder la compatibilité avec les anciens chargeurs, cette information peut être passée via le plugin:

 plugins: 

debug

L’option debug a fait passer les chargeurs en mode débogage dans webpack 1. Cela doit être passé via les options du chargeur à long terme. Voir la documentation des chargeurs pour les options pertinentes.

Le mode débogage pour les chargeurs sera supprimé dans webpack 3 ou plus.

Pour garder la compatibilité avec les anciens chargeurs, les chargeurs peuvent être passés en mode débogage via un plugin:

- debug: true, plugins: 

Fractionnement du code avec ES2015

Dans webpack 1, vous pouviez utiliser require.ensure() comme méthode pour charger paresseusement des chunks pour votre application:

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

La spécification du chargeur ES2015 définit import() comme méthode pour charger dynamiquement les modules ES2015 à l’exécution. webpack traite import() comme un split-point et place le module demandé dans un chunk séparé. import() prend le nom du module comme argument et renvoie une Promise.

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

Bonne nouvelle : L’échec du chargement d’un chunk peut maintenant être géré car ils sont basés sur Promise.

Expressions dynamiques

Il est possible de passer une expression partielle à import(). Ceci est géré de manière similaire aux expressions dans CommonJS (webpack crée un contexte avec tous les fichiers possibles).

import() crée un chunk séparé pour chaque module possible.

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

Mélange de l’ES2015 avec AMD et CommonJS

Comme pour AMD et CommonJS, vous pouvez librement mélanger les trois types de modules (même dans le même fichier). Dans ce cas, webpack se comporte de manière similaire à babel et à 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';

Il est important de noter que vous voudrez indiquer à Babel de ne pas analyser ces symboles de module afin que webpack puisse les utiliser. Vous pouvez le faire en définissant ce qui suit dans vos options .babelrc ou babel-loader.

.babelrc

{ "presets": ]}

Hints

Pas besoin de changer quelque chose, mais des opportunités

Chaînes de modèles

webpack supporte maintenant les chaînes de modèles dans les expressions. Cela signifie que vous pouvez commencer à les utiliser dans les constructions de webpack:

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

Configuration Promise

webpack supporte maintenant le retour d’un Promise du fichier de configuration. Cela permet un traitement asynchrone dans votre fichier de configuration.

webpack.config.js

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

Mise en correspondance avancée des chargeurs

webpack supporte maintenant plus de choses sur lesquelles correspondre pour les chargeurs.

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

Plus d’options CLI

Il y a quelques nouvelles options CLI que vous pouvez utiliser :

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

--display-depth affiche la distance au point d’entrée pour chaque module.

--display-used-exports affiche des infos sur les exportations utilisées dans un module.

--display-max-modules définit le nombre pour les modules affichés dans la sortie (par défaut, 15).

-p définit également process.env.NODE_ENV à "production" maintenant.

Loader changes

Changements seulement pertinents pour les auteurs de chargeurs.

Cacheable

Les chargeurs sont maintenant cacheables par défaut. Les chargeurs doivent se désengager s’ils ne sont pas cachables.

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

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

Options complexes

webpack 1 ne prend en charge que les options JSON.stringify-ables pour les chargeurs.

webpack 2 prend désormais en charge n’importe quel objet JS comme options de chargeurs.