Recentemente, alguns artigos interessantes apareceram em Habré. O primeiro foi dedicado ao problema de
minificação do
ES6 , o segundo sobre
dicas gerais de
otimização de webpack úteis .
Tudo ficaria bem, mas ambos ignoraram a questão de dividir pacotes configuráveis no ES6 e ES5 para fins de minificação e outros fins de otimização. E, em geral, enquanto alguns escrevem e escrevem
artigos sobre o assunto , outros (quase todos) ignoram essa técnica.
Porque por muito tempo. Caro E nem tanto.
Mas é necessário de forma rápida, barata e estúpida. Talvez você devesse reverter a evolução.

Idéia
Descrever uma "ideia" não é uma boa ideia. É melhor descrever como deve funcionar. Como o processo de formação de pacotes deve funcionar:
- Eu tenho um código
- Eu o compilo no meu navegador "desenvolvimento"
- e tudo funciona.
O navegador de desenvolvimento está aqui - para que assíncrono / espera, gerador, classes, funções de seta e assim por diante. Em geral, alvo: esmodules na babel.
Não conheço você, mas gosto dessa ideia. Aqui estão apenas os navegadores antigos que ainda estão entre nós, essa ideia não se encaixa dessa maneira.
(e, portanto, todos nós silvamos es5 em produção, temperando com meio megabyte de polifills)E é exatamente isso que precisa ser corrigido.Devolução
O Devolution é um pequeno utilitário cli que leva seu pacote compilado para o destino: esmodules e o degrada para es5, adicionando todos os polyfiles necessários ao longo do caminho.
Em suma, então:
- todos os scripts js são
- execute o babel com um plug-in ativo (fork useBuiltins: “use”) que define os polyfiles necessários. Isso é rápido, pois não há transformações.
- para cada arquivo, todos os polyphiles necessários são coletados (menos os que já estão no pacote principal), mesclados, executados no terser e adicionados à parte superior do arquivo.
- cada arquivo será executado através do swc, uma versão enferrujada do babel que atualiza o código para um nível que o IE11 entende. Funciona 10 a 60 vezes mais rápido que o babel. Ele não suporta vários plugins, mas isso não é necessário - tudo o que é necessário é __ já__ aplicado.
- O terser é novamente sobreposto ao resultado, mas com o mangle desativado (compactação de nome), o que novamente é rápido.
- Tudo isso é feito nos trabalhadores.
Eu executei o código em três projetos de diferentes níveis de dificuldade:
- projeto 1, 60 arquivos js finais (divisão de código). Tempo de construção 400s. Devolução 30s.
- projeto 2, 1 arquivo js final (30mb). Tempo de construção 120s. Devolução 10s.
- projeto 3, 1 arquivo js final (2mb). Tempo de construção 20s. Devolução 5s (no início dos trabalhadores, muitas coisas são perdidas).
O bônus do pacote ESM foi um pouco estranho:
- um projeto perdeu 400kb babel / polyfill. Nada de "over" chips de navegador foi usado lá banalmente, e no "esm" eles não precisam ser polidos
- um projeto perdeu 10% devido ao código muito mais compacto de geradores, construtores assíncronos / aguardados e de classe
- Um projeto ficou mais gordo, pois transformações "soltas" de babel às vezes tornam o código mais compacto. Mas o modo solto é uma opção um pouco perigosa, enquanto o código “ES6” é “seguro”.
Mais uma vez:
- tomamos o código ES6 (mais precisamente esmodule, let / const será substituído por var para fins de velocidade)
- faça disso ES5
- jogue no lado de polyphiles
- espalhe nos pais, adicione links simbólicos a outros arquivos
- alteramos a conexão de scripts para páginas para um pouco mais inteligente (os módulos / nomeações do IE11 não entendem)
- done - ESM para 85% dos medidores personalizados, ES5 para aqueles no tanque.
Simples. Rápido. Apenas estúpido. Nós demos upgrade do pacote. Navegadores antigos! Servido.
Bem, os novos navegadores receberão um pacote quase sem polyfills, sem terríveis transformações de geradores e assíncrono / aguardar, com funções de seta sem pandeiros (e geralmente são mais rápidos). Em geral, todo mundo está feliz, parece que isso foi originalmente planejado.
github.com/thekashey/devolutionPS: Atualmente, a devolução não usa swc , pois às vezes faz com que o código não funcione - github.com/swc-project/swc/issues/280 , Babel não é muito mais lento - onde swc foi corrigido em 20 segundos, babel pode fazê-lo em um minuto. Com um tempo de construção "normal" - a partir de 5 em diante - essa é uma grande vantagem
PS: Se de repente se tornou interessante por que a devolução é um
vídeo aqui .