Image for post
Image for post
A complexidade indispensável do desenvolvimento front-end de hoje!

O que há de novo no webpack 2?

Muita coisa mudou! Vários problemas resolvidos e muitos projetos para atualizar, veja o que está por vir na nossa complexidade favorita de hoje em dia!

Mudanças principais

As novidades abaixo são referentes à versão 2.0.5-beta+.

webpack 2 trás suporte nativo para módulos ES6. Isso significa, que agora, o webpack entende import e export sem precisar transforma-los em módulos CommonJS:

import { pagina, proxPagina } from “./livro”;pagina === 0;
proxPagina();
pagina === 1;

E então:

// livro.jsexport var pagina = 0;export function proxPagina() {
pagina++;
}
export default “Isso é um livro”;

A especificação do ES6 usa, por padrão, System.import para importar módulos de maneira dinâmica em tempo de execução.

webpack trata o System.import como ponto de divisão e coloca o módulo importado em um pedaço separado (chunk, em inglês).

System.import recebe o nome do módulo como argumento e retorna uma Promise.

function onClick() {System.import(“./meuModulo”).then(module => {
module.default;
}).catch(err => {
console.log(“Erro ao carregar o módulo”);
});
}

Boa novidade: A falha no carregamento de um pedaço separado agora pode ser tratado.

É possível passar uma expressão parcial para o System.import. Elas são tratadas de um jeito semelhante as expressões do CommonJS (webpack cria um contexto com todos os arquivos possíveis).

function route(path, query) {
return System.import(“./routes/” + path + “/route”)
.then(route => new route.Route(query));
}
// Isso cria um pedaço separado (chunk) para cada rota possível.

Enquanto AMD e CommonJS você pode livremente misturar os três tipos de importação (mesmo dentro de um arquivo). webpack funciona, neste caso, semelhante ao Babel:

// CommonJS consumindo um módulo ES6
var livro = require(“./livro”);
livro.pagina;
livro.proxPagina();
livro.default === “Isso é um livro”;

E então:

// Módulo ES6 consumindo CommonJS
import fs from “fs”; // module.exports é mapeado para `default`;
import { readFileSync } from “fs”; // exportações nomeadas são lidas do objeto retornado
typeof fs.readFileSync === “function”;
typeof readFileSync === “function”;

O preset do Babel es2015, por padrão, transforma todos os módulos ES6 em módulos CommonJS. Para usar o webpack para processar os módulos ES6, você deve usar o preset es2015-webpack.

A natureza estática dos módulos ES6 permitem um novo tipo de otimização. Por exemplo, em vários casos, é possível analisar quais exports estão sendo usados e quais não.

Em casos onde o webpack analisar que o export não está sendo usado, ele irá omitir essa declaração para outros módulos. Em uma etapa seguinte, o minimizador irá marcar essa declaração como não usada e irá omitir o mesmo do arquivo final.

Nos casos a seguir, é possível essa análise:

  • imports nomeados
  • imports padrões
  • re-exportação

Nos casos a seguir, não é possível essa análise:

  • import * as
  • CommonJS ou AMD consumindo módulos ES6
  • System.import

Em casos onde é possível analisar o uso do export, webpack pode transformar os exports para propriedades de apenas uma letra.

No passado, variáveis de ambiente eram muito usadas para cuidar de diferentes configurações. webpack 2 trás uma nova maneira de passar opções para suas configurações.

O arquivo de configuração pode exportar uma função que retorna a configuração. A função é chamada pela CLI e o valor é passado pelo parâmetro --env para a função de configuração.

Você pode passar como string (--env dev, será, "dev") ou um objeto complexo de opções (--env.minimize --env.server localhost, será, { minimize: true, server: "localhost" }). Eu recomendo o uso de um objeto, pelo simples fato de ser mais flexível, mas vai de você!

E então:

// webpack.config.babel.js
exports default function(options) {
return {
// ...
devtool: options.dev ?
"cheap-module-eval-source-map" :
"hidden-source-map"
};
}

Houve uma grande refatoração no módulo resolve. Isso significa que as opções também mudaram. Todas para simplificar a configuração e evitar configurações de formas incorretas.

As novas opções são:

{
modules: [path.resolve(__dirname, “app”), “node_modules”]
// (essa opção era dividida em `root`, `modulesDirectories` e
// `fallback` nas opções antigas)
// Onde o resolver iria olhar cada pasta na procura de módulos
// caminhos relativos são procurados em cara pasta pai (como
// node_modules)
// caminhos absolutos são procurados diretamente
// a ordem é respeitada
descriptionFiles: [“package.json”, “bower.json”],
// Esses arquivos JSON serão lidos nos diretórios

mainFields: [“main”, “browser”],
// Esses campos nos arquivos de descrição serão procurados
// primeiramente ao tentar resolver o diretório

mainFiles: [“index”]
// Esses arquivos serão procurados ao tentar resolver o
// diretório

aliasFields: [“browser”],
// Esses campos nos arquivos de descrição oferecem
// um alias para esse pacote
// O conteúdo desses campos é um objeto que mapea
// sua chave ao valor correspondente
extensions: [“.js”, “.json”],
// Essas extensões são procuradas ao resolver o arquivo
enforceExtension: false,
// Se conter o valor `false`, também tentará não usar extensões
// para resolver o arquivo
// baseado na lista `extensions`
moduleExtensions: [“-loader”],
// Essas extensões são procuradas ao resolver o módulo

enforceModuleExtension: false,
// Se conter o valor `false`, também tentará não
// usar extensões para resolver o módulo
// baseado na lista `moduleExtensions`
alias: {
jquery: path.resolve(__dirname, “vendor/jquery-2.0.0.js”)
} // Esses alias são usados ao tentar resolver o módulo
}

Alterações menores, mas significativas!

As mudanças separam os conceitos de configuração e parametrização de plugins, otimizações e polyfills.

O carregador de arquivos divididos (chunk loader), é baseado em Promise. Isso significa, que você precisa prover um polyfill para Promise em navegadores antigos.

A especificação do ES6 usa promises e eu não quero incluir um polyfill em todos os bundles. Então, depende de você, baseado na sua aplicação, disponibilizar um polyfill, se necessário.

Verifique o suporte nativo em Can I use Promises?.

Você precisa definir um polyfill para Object.defineProperty se estiver usando módulos ES6, ou, se estiver usando o objeto module de outras maneiras do que module.exports, module.id, module.loaded ou module.hot.

Para módulos ES6, você também precisa do polyfill para Function.prototype.bind.

Não é novidade, mas você também precisa do polyfill Object.keys para require.context().keys().

Agora, a configuração para carregar módulos vai de encontro com resourcePath ao invés de resource. Isso significa que os parâmetros de query string não serão includos para encontrar seus recursos.

Um exemplo, era um problema com o Bootstrap, que complicava o valor da chave test na procura de fontes e images, mudando /\.svg$/ para /\.svg($|\?)/. Agora, você pode usar a forma mais simples.

Os carregadores agora resolvem os caminhos baseado no arquivo de configuração (ou a chave context, se especificado). Isso deve resolver alguns problemas com módulos usando npm link, que estavam fora do projeto atual.

Junto de outras mudanças, agora é possível escrever a seguinte configuração:

loaders: [
{
test: /\.css$/,
loaders: [
“style-loader”,
{ loader: “css-loader”, query: { modules: true } },
{
loader: “sass-loader”,
query: {
includePaths: [
path.resolve(__dirname, “minha-pasta”)
]
}
}
]
}
]

O plugin UglifyJsPlugin não coloca mais os carregadores em modo de minimização por padrão. A opção debug foi removida. Agora, os carregadores não devem ler suas configurações do arquivo do webpack, ao invés disso,você deve prover as opções através do plugin LoaderOptionsPlugin.

new webpack.LoaderOptionsPlugin({  test: /\.css$/,
// opcionalmente passando o campo `test`, `include` ou `exclude`
// se não conter o campo `test`, por padrão, afeta todos os
// carregadores

minimize: true,
debug: false,
options: {
// passar opções para o carregador
}
})

Isso acontece para separação de conceitos. Eu quero desabilitar chaves arbitrárias na configuração, possibilitando uma validação da configuração.

Muitos plugins agora recebem um objeto de configuração ou invés de múltiplos argumentos. Isso acontece porque é mais fácil de extender. Eles retornam um erro quando o estilo antigo de argumentos é usado.

No webpack 1, o sinal de atualização usava o Web Messaging API (postMessage). No webpack 2, usa o padrão de emissão de eventos. Isso significa que WebSockets será injetado no bundle.

Agora, webpack-dev-server injeta esse modo por padrão.

Isso deve permitir ao webpack-dev-server atualizar código em WebWorkers.

O plugin não é mais necessário, ordem de ocorrência agora é padrão.

require.ensure e AMD require, agora por padrão são assíncronos, mesmo se o pedaço de arquivo (chunk) já estiver carregado.

Créditos

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store