Webpack 4 e dividindo o arquivo de configuração em módulos

Olá Habr! Hoje vou falar sobre o Webpack 4 com a separação de código em módulos separados, além de soluções interessantes que ajudarão você a criar seu assembly do webpack 4. Mais rapidamente. No final, fornecerei ao meu assembly básico do webpack as ferramentas mais necessárias, que você poderá posteriormente para expandir. Esta montagem o ajudará a entender esse material e também poderá ajudá-lo a escrever sua implementação mais rapidamente e a resolver possíveis problemas mais rapidamente.

A principal ideologia deste assembly é a correta separação do código dentro do arquivo de configuração para facilitar o uso, a leitura e a limpeza do webpack.config.js. Os módulos e plug-ins necessários para as versões dev e prod (bem como para a separação de funcionalidades no arquivo principal) estarão localizados em uma pasta separada do webpack e importados a partir dele para conectar-se à configuração principal.

Por que essa abordagem é necessária?

Com o aumento gradual no número de módulos, plug-ins, etc., que sua montagem cria no webpack, o arquivo de configuração cresce aos trancos e barrancos. Com o tempo, esse arquivo se torna difícil de ler e alterá-lo para um projeto específico, se alguns módulos não forem utilizados, se torna mais difícil, mas você deseja algo universal. Portanto, é necessária uma organização clara do código.

Do que precisamos?

Usaremos o plugin webpack-merge .

Criamos a pasta webpack e retiramos todos os módulos individuais em arquivos separados. Por exemplo, webpack / pug.js, webpack / scss.js e exporta essas funções a partir deles.

Arquivo Pug.js

module.exports = function() { return { module: { rules: [ { test: /\.pug$/, loader: 'pug-loader', options: { pretty: true, }, }, ], }, }; }; 

O arquivo webpack.config.js . Neste arquivo, nós os conectamos e, com a ajuda deste plugin, nos conectamos de forma conveniente e rápida.

 const merge = require('webpack-merge'); const pug = require('./webpack/pug'); const common = merge([ { entry: { 'index': PATHS.source + '/pages/index/index.js', 'blog': PATHS.source + '/pages/blog/blog.js', }, output: { path: PATHS.build, filename: './js/[name].js', }, plugins: […], optimization: { … }, }, pug(), ]); 

Agora, se tivermos uma nova tarefa, para a qual precisamos de um novo módulo, plug-in, carregador, transfira-o para o módulo do hotel (arquivo) e coloque-o na pasta webpack e conecte-o ao arquivo de configuração principal, mantendo a configuração o mais limpa possível.

Configurações para produção e desenvolvimento

Agora, com a ajuda do banal, terminaremos nossa separação, para a qual pretendemos, e configuraremos nosso webpack para esses dois tipos de desenvolvimento, tornando finalmente conveniente o uso dessa ferramenta, e também no futuro poderemos configurá-la de forma flexível e simples para qualquer outro projeto, ou expandir no atual. Para exportar para um nó (para o próprio webpack) no webpack 4, usamos a seguinte construção:

 module.exports = function(env, argv) { if (argv.mode === 'production') { return merge([ common, extractCSS(), favicon(), ]); } if (argv.mode === 'development') { return merge([ common, devserver(), sass(), css(), sourceMap(), ]); } 

No objeto comum, conectamos o que é usado tanto no produto quanto no desenvolvimento e, nas condições, conectamos apenas os módulos necessários nesses casos.

Agora eu gostaria de falar sobre os principais recursos do webpack 4 em relação ao webpack 3

• Para começar rapidamente, o webpack 4 não precisa do webpack.config.js, agora precisa apenas de um ponto de entrada (index.js)
• Na nova versão, a interface da linha de comandos do webpack está em um pacote separado e você precisa instalar o webpack-cli.
• Para iniciar o webpack 4, você precisa (caso contrário, será um aviso) nos scripts, especificar modo (modo de operação) - produção em modo ou - desenvolvimento de modo, dependendo da chave, a operação do webpack muda. O modo de desenvolvimento visa acelerar a compilação. Na versão de produção, tudo visa a minificação final do código.
• Para criar arquivos common.js e common.css, o CommonsChunkPlugin não é mais usado, os splitChunks agora são responsáveis ​​por isso e a seguinte construção é usada:
  
  

    optimization: { splitChunks: { cacheGroups: { 'common': { minChunks: 2, chunks: 'all', name: 'common', priority: 10, enforce: true, }, }, }, }, 

  
  No webpack 3 - isso aconteceria nos plugins:
  
  

   new webpack.optimize.CommonsChunkPlugin({ name: 'common ', }) 

  
  Assim, nos blocos do HtmlWebpackPlugin nos conectamos (aqui sem alterações).
  
  

   plugins: [ new HtmlWebpackPlugin({ filename: 'index.html', chunks: ['index', 'common'], template: PATHS.source + '/pages/index/index.pug', }), ], 

  
  
• O próximo ponto importante, para criar o sourceMap, agora usamos a seguinte abordagem - criamos o arquivo sourceMap.js na pasta webpack e o conectamos na versão dev, por exemplo (como mencionado acima):
  
  

   module.exports = function() { return { devtool: 'eval-sourcemap', }; }; 

Agora, os plugins se aproximam : [new webpack.optimize.UglifyJsPlugin ({})] não funciona.

Com isso, gostaria de completar minha história e fornecer minha montagem básica - um link para o webpack 4, que provavelmente o ajudará em seu trabalho e desenvolvimento. Obrigado pela atenção!