As secções seguintes descrevem as principais alterações do webpack 1 para 2.

resol.root, resol.fallback, resol.modulesDirectories

Estas opções foram substituídas por uma única opção resolve.modules. Veja resolvendo para mais uso.

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

resol.extensions

Esta opção não requer mais a passagem de uma string vazia. Este comportamento foi movido para resolve.enforceExtension. Veja resolvendo para mais uso.

resolve.*

As APIseverais foram alteradas aqui. Não listado em detalhes, pois não é comumente usado. Veja resolvendo para detalhes.

module.loaders é agora module.rules

A configuração do antigo loader foi substituída por um sistema de regras mais poderoso, que permite a configuração de loaders e muito mais. Por razões de compatibilidade, a antiga sintaxe module.loaders ainda é válida e os nomes antigos são analisados. As novas convenções de nomes são mais fáceis de entender e são uma boa razão para atualizar a configuração para usar module.rules.

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

Chaining loaders

Like no webpack 1, loaders podem ser encadeados para passar resultados de loader para loader. Usando a opção de configuração rule.use, use pode ser definido para um conjunto de carregadores. No webpack 1, os carregadores eram normalmente encadeados com !. Este estilo só é suportado usando a opção legada module.loaders.

 module: {- loaders: }] }

Automatic -automatic – extensão do nome do módulo carregador removida

Não é mais possível omitir a extensão -loader quando referenciar carregadores:

 module: { rules: } ] }

Você ainda pode optar pelo comportamento antigo com a opção de configuração resolveLoader.moduleExtensions, mas isto não é recomendado.

+ resolveLoader: {+ moduleExtensions: + }

Ver #2986 pelo motivo por trás desta alteração.

json-loader não é mais necessário

Quando nenhum loader foi configurado para um arquivo JSON, o webpack tentará automaticamente carregar o arquivo JSON com a opção json-loader.

 module: { rules: }

Decidimos fazer isso para eliminar as diferenças de ambiente entre webpack, node.js e browserify.

Loaders na resolução de configuração relativa ao contexto

No webpack 1, os carregadores configurados resolvem em relação ao arquivo correspondente. No entanto, no webpack 2, os carregadores configurados resolvem em relação ao arquivo context opção.

Isso resolve alguns problemas com módulos duplicados causados pelos carregadores ao usar npm link ou referenciando módulos fora do arquivo context.

Você pode remover alguns hacks para contornar isso:

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

module.preLoaders e module.postLoaders foram removidos:

 module: {- preLoaders: }

UglifyJsPlugin sourceMap

A opção sourceMap do UglifyJsPlugin agora por defeito para false em vez de true. Isto significa que se você estiver usando mapas fonte para código minimizado ou quiser números de linha corretos para avisos do uglifyJs, você precisa definir sourceMap: true para UglifyJsPlugin.

 devtool: "source-map", plugins: 

avisos do UglifyJsPlugin

A opção compress.warnings do UglifyJsPlugin agora tem como padrão false em vez de true. Isto significa que se você quiser ver avisos do uglifyJsPlugin, você precisa definir compress.warnings para true.

 devtool: "source-map", plugins: 

UglifyJsPlugin minimizar carregadores

>UglifyJsPlugin não mais mudar carregadores para o modo minimizar. A configuração minimize: true precisa ser passada através das opções da carregadeira a longo prazo. Veja a documentação da carregadeira para opções relevantes.

O modo minimizar para carregadeiras será removido no webpack 3 ou posterior.

Para manter a compatibilidade com carregadeiras antigas, as carregadeiras podem ser trocadas para o modo minimizar via plugin:

 plugins: 

O DedupePlugin foi removido

webpack.optimize.DedupePlugin não é mais necessário. Remove-o da sua configuração.

BannerPlugin – mudança de quebra

BannerPlugin já não aceita dois parâmetros, mas um único objecto de opções.

 plugins: 

OcorrênciaOrderPlugin está agora activo por defeito

O OccurrenceOrderPlugin está agora activo por defeito e foi renomeado (OccurenceOrderPlugin no webpack 1). Assim, certifique-se de remover o plugin da sua configuração:

 plugins: 

ExtractTextWebpackPlugin – alteração de quebra

ExtractTextPlugin requer a versão 2 para funcionar com o webpack 2.

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

As alterações de configuração para este plugin são principalmente sintácticas.

module: { rules: }

novo ExtractTextPlugin({opções})

plugins: 

A dinâmica completa requer agora falha por defeito

Uma dependência com apenas uma expressão (ou seja require(expr)) irá agora criar um contexto vazio em vez do contexto do directório completo.

Código como este deve ser refacturado uma vez que não irá funcionar com os módulos ES2015. Se isto não for possível você pode usar o ContextReplacementPlugin para sugerir ao compilador a resolução correta.

Usar argumentos personalizados na CLI e na configuração

Se você abusou da CLI para passar argumentos personalizados para a configuração assim:

webpack --custom-stuff

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

Você pode notar que isto não é mais permitido. O CLI é mais rigoroso agora.

Em vez disso, existe uma interface para passar argumentos à configuração. Esta deve ser usada em seu lugar. Futuras ferramentas podem depender disto.

webpack --env.customStuff

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

Ver CLI.

require.ensure e AMD require são assíncronas

Estas funções são agora sempre assíncronas em vez de chamarem a sua chamada de retorno de forma síncrona se o pedaço já estiver carregado.

require.ensure agora depende do nativo Promises. Se utilizar require.ensure num ambiente que não os tenha, então necessitará de um polyfill.

A configuração do carregador é através das opções

Já não pode configurar um carregador com uma propriedade personalizada em webpack.config.js. Deve ser feito através das opções options. A seguinte configuração com a propriedade ts não é mais válida com o webpack 2:

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

O que são opções?

Pergunta boa. Bem, estritamente falando são 2 coisas possíveis; ambas as maneiras de configurar um carregador de webpack. Classicamente options foi chamado query e era uma string que podia ser anexada ao nome do carregador. Muito parecido com uma query string mas na verdade com maiores poderes:

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

Mas também pode ser um objeto especificado separadamente que é fornecido junto com um carregador:

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

LoaderOptionsPlugin context

Alguns carregadores precisam de informações de contexto e lê-las a partir da configuração. Isto precisa ser passado através de opções de carregadeira a longo prazo. Veja a documentação do carregador para opções relevantes.

Para manter a compatibilidade com carregadores antigos, esta informação pode ser passada via plugin:

 plugins: 

debug

A opção debug comutou carregadores para o modo de debug no webpack 1. Isto precisa ser passado através de opções de carregadores a longo prazo. Veja a documentação do carregador para opções relevantes.

O modo de depuração para carregadores será removido no webpack 3 ou posterior.

Para manter a compatibilidade com carregadores antigos, os carregadores podem ser trocados para o modo de depuração através de um plugin:

- debug: true, plugins: 

Dividir código com ES2015

No webpack 1, você pode usar require.ensure() como um método para carregar blocos preguiçosos para sua aplicação:

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

A especificação do carregador ES2015 define import() como método para carregar os Módulos ES2015 dinamicamente em tempo de execução. O webpack trata import() como um ponto dividido e coloca o módulo solicitado em um pedaço separado. import() toma o nome do módulo como argumento e retorna um Promise.

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

Bom notícias: A falha em carregar um trecho pode agora ser resolvida porque são Promise baseadas.

Expressões dinâmicas

É possível passar uma expressão parcial para import(). Isto é tratado de forma similar às expressões em CommonJS (o webpack cria um contexto com todos os arquivos possíveis).

import() cria um trecho separado para cada módulo possível.

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

Misturar ES2015 com AMD e CommonJS

Como para AMD e CommonJS você pode misturar livremente os três tipos de módulo (mesmo dentro do mesmo arquivo). O webpack se comporta de forma similar ao babel e neste caso, acena com um sinal sonoro:

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

É importante notar que você vai querer dizer ao Babel para não analisar estes símbolos de módulo para que o webpack possa usá-los. Você pode fazer isso definindo o seguinte no seu .babelrc ou babel-loader opções.

.babelrc

{ "presets": ]}

Dicas

Não é necessário mudar nada, mas oportunidades

Template strings

webpack agora suporta strings de modelos em expressões. Isto significa que você pode começar a usá-las em construções de webpack:

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

Configuração Promessa

webpack agora suporta retornar um Promise do arquivo de configuração. Isto permite o processamento async no seu ficheiro de configuração.

webpack.config.js

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

Advanced loader matching

webpack agora suporta mais coisas a combinar para carregadores.

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

Mais opções CLI

Existem algumas novas opções CLI para você usar:

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

--display-depth mostra a distância até o ponto de entrada de cada módulo.

--display-used-exports mostra informações sobre quais exportações são usadas em um módulo.

--display-max-modules define o número de módulos exibidos na saída (o padrão é 15).

-p também define process.env.NODE_ENV a "production" now.

Mudanças de carregador

Alterações relevantes apenas para os autores do carregador.

Cacheável

Os carregadores são agora cacheáveis por padrão. Os carregadores têm de optar por não ser armazenados em cache.

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

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

Opções complexas

webpack 1 suporta apenas JSON.stringifyopções de cache para carregadores.

webpack 2 suporta agora qualquer objecto JS como opções de carregadores.