Começando com o Webpack

Nos primeiros dias, quando a modularidade foi introduzida no JavaScript, não havia suporte nativo para a execução de módulos no navegador. O suporte para programação modular estava sendo implementado em Node.js usando o blueprint CommonJS e estava sendo adotado por aqueles que usavam JavaScript para construir aplicativos do lado do servidor.

Ele também tinha perspectivas para grandes aplicativos da Web, pois os desenvolvedores poderiam evitar colisões de namespace e construir bases de código mais sustentáveis ​​escrevendo código em um padrão mais modular. Mas ainda havia um desafio: os módulos não podiam ser usados ​​em navegadores da web, onde o JavaScript geralmente era executado.

Para resolver esse problema, bundlers de módulo como webpack, Parcel, Rollup e também o Closure Compiler do Google foram escritos para criar pacotes otimizados de seu código para o navegador do usuário final baixar e executar.

O que significa “agrupar” seu código?

O código de pacote se refere à combinação e otimização de vários módulos em um ou mais pacotes prontos para produção . O pacote aqui mencionado pode ser entendido melhor como o produto final de todo o processo de pacote.

Neste artigo, focaremos no webpack, uma ferramenta escrita por Tobias Koppers, que ao longo do tempo cresceu e se tornou uma ferramenta importante dentro da cadeia de ferramentas JavaScript, frequentemente usada em projetos grandes e pequenos.

Observação: para se beneficiar deste artigo, é uma boa ideia estar familiarizado com os módulos JavaScript. Você também precisará do Node instalado em sua máquina local, para poder instalar e usar o webpack localmente.

O que é webpack?

webpack é um empacotador de módulo estático altamente extensível e configurável para aplicativos JavaScript. Com sua natureza extensível, você pode conectar carregadores e plugins externos para atingir seu objetivo final.

Conforme mostrado na ilustração abaixo, o webpack percorre seu aplicativo a partir de um ponto de entrada raiz , cria um gráfico de dependência composto de dependências que atuam direta ou indiretamente no arquivo raiz e produz pacotes otimizados dos módulos combinados.

Para entender como o webpack funciona, precisamos entender algumas terminologias que ele usa (verifique o glossário do webpack. Esta terminologia é frequentemente usada neste artigo, e também é frequentemente referenciada na documentação do webpack.

• Pedaço
  Um pedaço refere-se ao código extraído dos módulos. Este código será armazenado em um arquivo chunk . Os pedaços são comumente usados ​​ao executar a divisão de código com o webpack.
• Módulos
  Os módulos são partes divididas do seu aplicativo que você importa para executar uma tarefa ou função específica. O Webpack suporta módulos criados usando a sintaxe ES6, CommonJS e AMD.
• Bens
  O termo assets é frequentemente usado dentro do webpack e outros bundlers em geral. Refere-se aos arquivos estáticos agrupados durante o processo de compilação. Esses arquivos podem ser qualquer coisa, desde imagens a fontes ou até mesmo arquivos de vídeo. À medida que você ler mais adiante no artigo, verá como usamos carregadores para trabalhar com diferentes tipos de ativos.

Leitura recomendada : Webpack - Uma introdução detalhada

Uma vez que tenhamos entendido o que é webpack e qual terminologia ele usa, vamos ver como eles se aplicam na montagem de um arquivo de configuração para um projeto de demonstração.

Nota : Você também precisará webpack-cli instalado para usar o webpack em sua máquina. Se não estiver instalado, você será solicitado a partir do seu terminal para instalá-lo.

Arquivos de configuração do webpack

Além de usar o webpack-cli de um terminal, você também pode usar o webpack em seu projeto por meio de um arquivo de configuração. Mas com as versões recentes do webpack, podemos usá-lo em nosso projeto sem um arquivo de configuração. Podemos usar webpack como um valor de um dos comandos em nosso arquivo package.json — sem nenhum sinalizador. Dessa forma, o webpack assumirá que o arquivo de ponto de entrada do seu projeto está no diretório src . Ele agrupará o arquivo de entrada e o enviará para o diretório dist .

Um exemplo é o arquivo package.json de amostra abaixo. Aqui, usamos o webpack para agrupar o aplicativo sem um arquivo de configuração:

 { "name" : "Smashing Magazine", "main": "index.js", "scripts": { "build" : "webpack" }, "dependencies" : { "webpack": "^5.24.1" } }

Ao executar o comando build no arquivo acima, o webpack agrupará o arquivo no diretório src/index.js e o enviará em um arquivo main.js em um diretório dist . webpack é, no entanto, muito mais flexível do que isso. Podemos alterar o ponto de entrada , ajustar o ponto de saída e refinar muitos outros comportamentos padrão editando um arquivo de configuração com o sinalizador -- config .

Um exemplo é o comando build modificado do arquivo package.json acima:

 "build" : "webpack --config webpack.config.js"

Acima, adicionamos o sinalizador --config e especificamos um webpack.config.js como o arquivo com a nova configuração do webpack.

O arquivo webpack.config.js ainda não existe. Portanto, precisamos criá-lo em nosso diretório de aplicativos e colar o seguinte código abaixo no arquivo.

 # webpack.config.js const path = require("path") module.exports = { entry : "./src/entry", output : { path: path.resolve(__dirname, "dist"), filename: "output.js" } }

O arquivo acima ainda configura o webpack para agrupar seu arquivo JavaScript, mas agora podemos definir uma entrada personalizada e caminhos de arquivo de saída em vez do caminho padrão usado pelo webpack.

Algumas coisas a serem observadas sobre um arquivo de configuração do webpack:

• Um arquivo de configuração do webpack é um arquivo JavaScript, escrito como um módulo JavaScript CommonJS.
• Um arquivo de configuração do webpack exporta um objeto com várias propriedades. Cada uma dessas propriedades é usada como uma opção para configurar o webpack ao agrupar seu código. Um exemplo é a opção de mode :
  • mode
    Na configuração, esta opção é usada para definir o valor NODE_ENV durante o empacotamento. Pode ter um valor de production ou de development . Quando não especificado, o padrão será none . Também é importante observar que o webpack agrupa seus ativos de maneira diferente com base no valor do mode . Por exemplo, o webpack armazena automaticamente seus pacotes em cache no modo de desenvolvimento para otimizar e reduzir o tempo do pacote. Consulte a seção de modo da documentação do webpack para ver um registro de alterações das opções aplicadas automaticamente em cada modo.
    

Conceitos do webpack

Ao configurar o webpack por meio da CLI ou de um arquivo de configuração, existem quatro conceitos principais que são aplicados como opções . A próxima seção deste artigo se concentra nesses conceitos e os aplica ao criar a configuração de um aplicativo Web de demonstração.

Observe que os conceitos explicados abaixo compartilham algumas semelhanças com outros empacotadores de módulos. Por exemplo, ao usar Rollup com um arquivo de configuração, você pode definir um campo de entrada para especificar o ponto de entrada do gráfico de dependência, um objeto de saída configurando como e onde os pedaços produzidos são colocados e também um objeto de plugins para adicionar plugins externos.

Entrada

O campo de entrada em seu arquivo de configuração contém o caminho para o arquivo de onde o webpack começa a construir um gráfico de dependência . A partir deste arquivo de entrada, o webpack seguirá para outros módulos que dependem direta ou indiretamente do ponto de entrada.

O ponto de entrada da sua configuração pode ser do tipo Single Entry com um único valor de arquivo, semelhante ao exemplo abaixo:

 # webpack.configuration.js module.exports = { mode: "development", entry : "./src/entry" }

O ponto de entrada também pode ser um tipo de entrada multi-principal com uma matriz contendo o caminho para vários arquivos de entrada, semelhante ao exemplo abaixo:

 # webpack.configuration.js const webpack = require("webpack") module.exports = { mode: "development", entry: [ './src/entry', './src/entry2' ], }

Saída

Assim como o nome indica, o campo de saída de uma configuração é onde o pacote criado ficará. Este campo é útil quando você tem vários módulos instalados. Em vez de usar o nome gerado pelo webpack, você pode especificar seu próprio nome de arquivo .

 # webpack.configuration.js const webpack = require("webpack"); const path = require("path"); module.exports = { mode: "development", entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), } }

Carregadores

Por padrão, o webpack entende apenas arquivos JavaScript dentro de seu aplicativo. No entanto, o webpack trata cada arquivo importado como um módulo como uma dependência e o adiciona ao gráfico de dependência. Para processar recursos estáticos como imagens, arquivos CSS, arquivos JSON ou até mesmo seus dados armazenados em CSV, o webpack usa carregadores para “carregar” esses arquivos no pacote.

Os carregadores são flexíveis o suficiente para serem usados ​​para muitas coisas, desde transpilar seu código ES, manipular os estilos do seu aplicativo ou até mesmo fazer o linting do seu código com ESLint.

Existem três maneiras de usar carregadores em seu aplicativo. Uma delas é através do método inline importando-o diretamente no arquivo. Por exemplo, para minimizar o tamanho da imagem, podemos usar o image-loader carregador de imagens diretamente no arquivo, conforme mostrado abaixo:

 // main.js import ImageLoader from 'image-loader'

Outra opção preferida para usar carregadores é através do arquivo de configuração do webpack. Dessa forma, você pode fazer mais com os carregadores, como especificar os tipos de arquivo aos quais deseja aplicar os carregadores. Para fazer isso, criamos um array de rules e especificamos os carregadores em um objeto, cada um com um campo de teste com uma expressão regex que corresponde aos ativos aos quais queremos aplicar os carregadores.

Por exemplo, com image-loader importado diretamente no exemplo anterior, podemos usá-lo no arquivo de configuração do webpack com as opções mais básicas da documentação. Isso ficará assim:

 # webpack.config.js const webpack = require("webpack") const path = require("path") const merge = require("webpack-merge") module.exports = { mode: "development", entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), }, module: { rules: [ { test: /\.(jpe?g|png|gif|svg)$/i, use: [ 'img-loader' ] } ] } }

Dê uma olhada no campo de test no objeto que contém o image-loader acima. Podemos identificar a expressão regex que corresponde a todos os arquivos de imagem: formato jp(e)g , png , gif e svg .

O último método de uso de Loaders é via CLI com o --module-bind .

O readme awesome-webpack contém uma lista exaustiva de carregadores que você pode usar com o webpack, cada um agrupado em categorias de operações que eles executam. Abaixo estão apenas alguns carregadores que você pode achar úteis em sua aplicação:

• Carregador responsivo Você achará este carregador muito útil ao adicionar imagens para se adequar ao seu site ou aplicativo responsivo. Ele cria várias imagens de vários tamanhos a partir de uma única imagem e retorna um srcset correspondente às imagens para uso em tamanhos de tela de exibição apropriados.
• Babel-loader
  Isso é usado para transpilar seu código JavaScript da sintaxe ECMA moderna para o ES5.
• GraphQL-Loader
  Se você é um entusiasta do GraphQL, achará esse carregador bastante útil, pois ele carrega seus arquivos .graphql contendo seu esquema, consultas e mutações do GraphQL — juntamente com a opção de habilitar a validação.

Plug-ins

O uso de plugins permite que o compilador webpack execute tarefas em pedaços produzidos a partir dos módulos empacotados. Embora o webpack não seja um executor de tarefas, com plugins, podemos realizar algumas ações personalizadas que os carregadores não podiam executar quando o código estava sendo empacotado.

Um exemplo de plug-in do webpack é o ProgressPlugin integrado ao webpack. Ele fornece uma maneira de personalizar o progresso que é impresso no console durante a compilação.

 # webpack.config.js const webpack = require("webpack") const path = require("path") const merge = require("webpack-merge") const config = { mode: "development", entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), }, module: { rules: [ { test: /\.(jpe?g|png|gif|svg)$/i, use: [ 'img-loader' ] } ] }, plugins: [ new webpack.ProgressPlugin({ handler: (percentage, message ) => { console.info(percentage, message); }, }) ] } module.exports = config

Com o plugin Progress na configuração acima, fornecemos uma função de manipulador que imprimirá a porcentagem de compilação e a mensagem para o console durante o processo de compilação.

Abaixo estão alguns plugins do readme awesome-webpack que você achará útil em seu aplicativo webpack.

• Plug-in off-line
  Este plug-in utiliza os service workers primeiro ou o AppCache, quando disponível, para fornecer uma experiência offline para projetos gerenciados pelo webpack.
• Purgecss-webpack-plugin
  Este plugin é útil ao tentar otimizar seu projeto webpack, pois remove CSS não utilizado em seu aplicativo durante a compilação.
  

Neste ponto, temos nossa primeira configuração de webpack para um aplicativo relativamente pequeno totalmente configurado. Vamos considerar ainda como podemos fazer certas coisas com o webpack em nosso aplicativo.

Lidando com vários ambientes

Em seu aplicativo, pode ser necessário configurar o webpack de forma diferente para um ambiente de desenvolvimento ou produção . Por exemplo, talvez você não queira que o webpack gere pequenos logs de aviso sempre que uma nova implantação for feita em seu pipeline de integração contínua em seu ambiente de produção.

Existem várias maneiras de conseguir isso, conforme recomendado pelo webpack e pela comunidade. Uma maneira é converter seu arquivo de configuração para exportar uma função que retorne um objeto. Desta forma, o ambiente atual será passado para a função pelo compilador webpack como seu primeiro parâmetro, e outra opção como o segundo parâmetro.

Este método de manipulação do seu ambiente webpack será útil se houver algumas operações que você gostaria de executar de forma diferente com base no ambiente atual. No entanto, para aplicativos maiores com configurações mais complexas, você pode acabar com uma configuração repleta de várias instruções condicionais.

O trecho de código abaixo mostra um exemplo de como lidar com um ambiente de production e development no mesmo arquivo usando o método de functions .

 // webpack.config.js module.exports = function (env, args) { return { mode : env.production ? 'production' : 'development', entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), }, plugins: [ env.development && ( new webpack.ProgressPlugin({ handler: (percentage, message ) => { console.info(percentage, message); }, }) ) ] } }

Percorrendo a função exportada no trecho de código acima, você verá como o parâmetro env passado para a função está sendo usado com um operador ternário para alternar valores. É usado primeiro para definir o modo webpack, depois também é usado para habilitar o ProgressPlugin apenas no modo de desenvolvimento.

Outra maneira mais elegante de lidar com seu ambiente de produção e desenvolvimento é criar arquivos de configuração diferentes para os dois ambientes. Depois de fazer isso, podemos usá-los com comandos diferentes nos scripts package.json ao agrupar o aplicativo. Dê uma olhada no trecho abaixo:

 { "name" : "smashing-magazine", "main" : "index.js" "scripts" : { "bundle:dev" : "webpack --config webpack.dev.config.js", "bundle:prod" : "webpack --config webpack.prod.config.js" }, "dependencies" : { "webpack": "^5.24.1" } }

No package.json acima, temos dois comandos de script , cada um usando um arquivo de configuração diferente escrito para lidar com um ambiente específico ao agrupar os ativos do aplicativo. Agora você pode agrupar seu aplicativo usando npm run bundle:dev no modo de desenvolvimento ou npm run bundle:prod ao criar um pacote pronto para produção.

Usando a segunda abordagem, você evita instruções condicionais introduzidas ao retornar seu objeto de configuração de uma função. No entanto, agora você também precisa manter vários arquivos de configuração.

Arquivo de configuração de divisão

Neste ponto, nosso arquivo de configuração do webpack está em 38 linhas de código (LOC). Isso é muito bom para um aplicativo de demonstração com um único carregador e um único plug-in.

No entanto, para um aplicativo maior, nosso arquivo de configuração do webpack será definitivamente muito mais longo, com vários carregadores e plugins com suas opções personalizadas cada. Para manter o arquivo de configuração limpo e legível, podemos dividir a configuração em objetos menores em vários arquivos e usar o pacote webpack-merge para mesclar os objetos de configuração em um arquivo base.

Para aplicá-lo ao nosso projeto webpack, podemos dividir o único arquivo de configuração em três arquivos menores: um para carregadores, outro para plugins e o último arquivo como o arquivo de configuração base onde juntamos os outros dois arquivos.

Crie um arquivo webpack.plugin.config.js e cole o código abaixo nele para usar os plugins com opções adicionais.

 // webpack.plugin.config.js const webpack = require('webpack') const plugin = [ new webpack.ProgressPlugin({ handler: (percentage, message ) => { console.info(percentage, message); }, }) ] module.exports = plugin

Acima, temos um único plugin que extraímos do arquivo webpack.configuration.js .

Em seguida, crie um arquivo webpack.loader.config.js com o código abaixo para os carregadores de webpack.

 // webpack.loader.config.js const loader = { module: { rules: [ { test: /\.(jpe?g|png|gif|svg)$/i, use: [ 'img-loader' ] } ] } }

No bloco de código acima, movemos o webpack img-loader para um arquivo separado.

Por fim, crie um arquivo webpack.base.config.js onde a configuração básica de entrada e saída para o aplicativo webpack será mantida junto com os dois arquivos criados acima.

 // webpack.base.config.js const path = require("path") const merge = require("webpack-merge") const plugins = require('./webpack.plugin.config') const loaders = require('./webpack.loader.config') const config = merge(loaders, plugins, { mode: "development", entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), } }); module.exports = config

Dando uma olhada no arquivo webpack acima, você pode observar o quão compacto ele é em comparação com o arquivo webpack.config.js original. Agora, as três partes principais da configuração foram divididas em arquivos menores e podem ser usadas individualmente.

Otimizando grandes compilações

À medida que você continua trabalhando em seu aplicativo por um período de tempo, seu aplicativo definitivamente crescerá em recursos e tamanho. À medida que isso acontece, novos arquivos serão criados, arquivos antigos serão modificados ou refatorados e novos pacotes externos serão instalados - tudo levando a um aumento no tamanho do pacote emitido pelo webpack.

Por padrão, o webpack tenta otimizar automaticamente os pacotes em seu nome se o modo de configuração estiver definido como production . Por exemplo, uma técnica que o webpack aplica por padrão (começando com o webpack 4+) para otimizar e reduzir o tamanho do seu pacote é o Tree-Shaking. Essencialmente, é uma técnica de otimização usada para remover código não utilizado. Em um nível simples durante o empacotamento, as instruções de importação e exportação são usadas para detectar módulos não utilizados antes de removê-los dos pacotes emitidos.

Você também pode otimizar manualmente seu pacote de aplicativos adicionando um objeto de optimization com determinados campos em seu arquivo de configuração. A seção de otimização da documentação do webpack contém uma lista completa de campos que você pode usar no objeto de optimization para otimizar seu aplicativo. Vamos considerar um dos 20 campos documentados.

• minimize
  Este campo booleano é usado para instruir o webpack a minimizar o tamanho do pacote. Por padrão, o webpack tentará fazer isso usando o TerserPlugin, um pacote de minificação de código enviado com o webpack.

A minificação se aplica a minimizar seu código removendo dados desnecessários do código, o que, por sua vez, reduz o tamanho do código produzido após o processo.

Também podemos usar outros minifiers preferidos adicionando um campo de array minimizer dentro do objeto de optimization . Um exemplo é o uso de Uglifyjs-webpack-plugin abaixo.

 // webpack.config.js const Uglify = require("uglifyjs-webpack-plugin") module.exports = { optimization { minimize : true, minimizer : [ new Uglify({ cache : true, test: /\.js(\?.*)?$/i, }) ] } }

Acima, uglifyjs-webpack-plugin está sendo usado como um minificador com duas opções bastante importantes. Primeiro, habilitar o cache significa que o Uglify só reduzirá os arquivos existentes quando forem novas alterações, e a opção de test especifica os tipos de arquivo específicos que queremos reduzir.

Nota: O uglifyjs-webpack-plugin fornece uma lista abrangente das opções disponíveis para uso ao reduzir seu código com ele.

Uma pequena demonstração de otimização

Vamos tentar otimizar manualmente um aplicativo de demonstração aplicando alguns campos em um projeto maior para ver a diferença. Embora não nos aprofundemos na otimização do aplicativo, veremos a diferença nos tamanhos dos pacotes ao executar o webpack no modo de development e no modo de production .

Para esta demonstração, usaremos um aplicativo de desktop construído com Electron que também usa React.js para sua interface do usuário — tudo empacotado junto com o webpack. Electron e React.js soam como uma combinação bastante pesada e provavelmente podem gerar um pacote maior.

Observação : se você está aprendendo sobre o Electron pela primeira vez, este artigo fornece uma boa visão do que é o Electron e como você pode usá-lo para criar aplicativos de desktop multiplataforma.

Para experimentar a demonstração localmente, clone o aplicativo do repositório GitHub e instale as dependências usando os comandos abaixo.

 # clone repository git clone https://github.com/vickywane/webpack-react-demo.git # change directory cd demo-electron-react-webpack # install dependencies npm install

O aplicativo de desktop é bastante simples com uma única página estilizada usando componentes estilizados. Quando o aplicativo de desktop é iniciado com o comando yarn start , a página única exibe uma lista de imagens obtidas de um CDN, conforme mostrado abaixo.

Vamos primeiro criar um pacote de desenvolvimento deste aplicativo sem nenhuma otimização manual para analisar o tamanho final do pacote.

A execução do yarn build:dev a partir de um terminal no diretório do projeto criará o pacote de desenvolvimento. Além disso, ele imprimirá as seguintes estatísticas no seu terminal:

O comando nos mostrará as estatísticas de toda a compilação e os pacotes emitidos.

Observe que o pedaço mainRenderer.js tem 1,11 Mebibyte (aproximadamente 1,16 MB). O mainRenderer é o ponto de entrada para o aplicativo Electron.

Em seguida, vamos adicionar uglifyjs-webpack-plugin como um plug-in instalado no arquivo webpack.base.config.js para minificação de código.

 // webpack.base.config.js const Uglifyjs = require("uglifyjs-webpack-plugin") module.exports = { plugins : [ new Uglifyjs({ cache : true }) ] }

Por fim, vamos executar o pacote do aplicativo com o webpack no modo de production . A execução do comando yarn build:prod do seu terminal produzirá os dados abaixo para o seu terminal.

Anote o pedaço mainRenderer desta vez. Ele caiu para impressionantes 182 Kibibytes (aproximadamente 186 KB), e isso é mais de 80% do tamanho do bloco mainRenderer emitido anteriormente!

Vamos visualizar ainda mais os pacotes emitidos usando o webpack-bundler-analyzer. Instale o plugin usando o comando yarn add webpack-bundle-analyzer e modifique o arquivo webpack.base.config.js para conter o código abaixo que adiciona o plugin.

 // webpack.base.config.js const Uglifyjs = require("uglifyjs-webpack-plugin"); const BundleAnalyzerPlugin = require("webpack-bundle-analyzer"); .BundleAnalyzerPlugin; const config = { plugins: [ new Uglifyjs({ cache : true }), new BundleAnalyzerPlugin(), ] }; module.exports = config;

Execute yarn build:prod do seu terminal para que o aplicativo seja reagrupado. Por padrão, o webpack-bundle-analyzer iniciará um servidor HTTP que fornece a visão geral visualizada dos pacotes configuráveis ​​em seu navegador.

Na imagem acima, podemos ver uma representação visual do pacote emitido e os tamanhos dos arquivos dentro do pacote. No visual, podemos observar que na pasta node_modules , o maior arquivo é o react-dom.production.min.js , seguido por stylis.min.js .

Usando os tamanhos de arquivo visualizados pelo analisador, teremos uma ideia melhor de qual pacote instalado está contribuindo com a maior parte do pacote. Podemos então procurar maneiras de otimizá-lo ou substituí-lo por um pacote mais leve.

Nota: A documentação do webpack-analyzer-plugin lista outros meios disponíveis para exibir a análise criada a partir de seus bundles emitidos.

Comunidade webpack

Um dos pontos fortes do webpack tem sido a grande comunidade de desenvolvedores por trás dele e isso tem sido de grande utilidade para os desenvolvedores que experimentam o webpack pela primeira vez. Assim como este artigo, existem vários artigos, guias e recursos com a documentação que serve como um ótimo guia ao usar o webpack.

Por exemplo, o guia Build Performance do blog do webpack contém dicas sobre como otimizar as compilações do seu webpack e o estudo de caso do Slack (embora um pouco antigo) explica como o webpack foi otimizado no Slack.

Vários recursos da comunidade explicam partes da documentação do webpack, fornecendo exemplos de projetos de demonstração para mostrar como os recursos do webpack estão sendo usados. Um exemplo é um artigo sobre Webpack 5 Module Federation que explica como o novo recurso Module Federation do webpack é usado em um aplicativo React.

Resumo

Após sete anos de existência, o webpack provou ser uma parte importante da cadeia de ferramentas JavaScript usada por um grande número de projetos. Este artigo apenas dá um vislumbre das coisas que podem ser alcançadas com a natureza flexível e extensível do webpack.

Da próxima vez que você precisar escolher um empacotador de módulos para seu aplicativo, esperamos que você entenda melhor alguns conceitos básicos do Webpack, o problema que ele resolve e também as etapas de configuração de seus arquivos de configuração.

Leitura adicional no SmashingMag:

• Webpack - Uma introdução detalhada
• Crie um PWA com Webpack e Workbox
• Configurando o TypeScript para projetos modernos do React usando o Webpack
• Como aproveitar as máquinas: ser produtivo com os executores de tarefas