Existem muitos pacotes webpack que encontram duplicados no pacote, o mais popular deles é o duplicado-pacote-verificador-webpack-plugin , mas requer a remontagem do projeto, e como havia uma tarefa de automatizar a seleção da versão ideal dos pacotes, a solução alternativa foi a sua.
Bem, ou a minha história é como acabou reduzindo o pacote em 15%, em alguns segundos.
Como em muitas empresas grandes que possuem uma enorme base de códigos, há muita lógica comum, como resultado, usamos componentes comuns publicados em nosso repositório npm. Eles são publicados pela lerna , respectivamente, antes de cada instalação ou atualização de componentes comuns, surge a questão de qual versão instalar. O lerna substitui todos os componentes que usam o componente publicado (se a versão era a mais recente). Por conseguinte, sempre existem versões de vários componentes que são mais adequados entre si, uma vez que não competem com dependências.
De projetos de código aberto dessa maneira, nivo , aqui está sua configuração lerna .
Como as dependências duplicadas aparecem então? E como eliminá-los?
Suponha que você tenha um projeto simples com o seguinte package.json :
{ "name": "demo-project", "version": "1.0.0", "dependencies": { "@nivo/bar": "0.54.0", "@nivo/core": "0.53.0", "@nivo/pie": "0.54.0", "@nivo/stream": "0.54.0" } }
Vamos ver onde o @nivo/core :
npm list @nivo/core
Vemos 4 cópias do @nivo/core (3 cópias de 0.54.0 e 1 - 0.53.0 ). Mas se mudarmos a versão secundária do @nivo/core para 0.54.0 , as duplicatas serão eliminadas.
O exemplo atual é simples, mas na prática, é claro, cada pacote tem mais dependências e você ainda precisa considerar as dependências ainda mais, o que aumenta a complexidade da tarefa.
E mais uma vez vendo o enorme tamanho do pacote, eu estava cansado de remover manualmente pacotes duplicados.
Em geral, é certo atualizar imediatamente os pacotes para a versão mais recente, mas não há tempo, como sempre, para alterar as versões principais, e é longo e difícil selecionar o pacote apropriado por pesquisa cega. Afinal, você precisa atualizar a versão da dependência no package.json , instalar novas dependências e verificar se duplicatas desapareceram na compilação; caso contrário, repita por um longo tempo, em média, 3-4 minutos por iteração.
Tudo isso é monótono e requer atenção, então decidi automatizar.
Gostaria de saber duplicatas sem reinstalar dependências e reconstruir o projeto, idealmente aplicativo cli que exibe opções de otimização em 10 segundos e todas as duplicatas existentes no projeto.
A eliminação das tomadas pode ser dividida em várias subtarefas, que serão consideradas em ordem.
Primeira tarefa Você precisa modelar a futura árvore de dependência de pacote configurável apenas por package.json, dada a desduplicação padrão, rapidamente, em não mais de 100ms.
Decidi usar o package-json para obter informações sobre pacotes e sempre para comparar versões diferentes.
O resultado foi um construtor de árvores de dependências do pacote npm, modelando de forma inteligente a árvore de dependências do pacote configurável apenas pelo package.json.
Alocado para um componente separado, porque talvez alguém o reutilize em tarefas combinatórias com o package.json.
A segunda tarefa Uma tarefa combinatória, uma enumeração eficiente de opções para alterar dependências e uma comparação de várias opções para árvores e, é claro, a escolha da melhor.
Tivemos que, de alguma forma, comparar qualitativamente as árvores resultantes, e tivemos que tomar emprestada a idéia de entropia, como medida quantitativa do distúrbio, tirando a soma de cópias duplicadas (do exemplo acima, é 3).
Seria ótimo levar em consideração os pesos dos pacotes (em KB), mas, infelizmente, não encontrei um pacote que funcionasse rapidamente com pesos, e aqueles que funcionam funcionam por cerca de meio minuto por pacote, por exemplo , tamanho do pacote . Como eles funcionam de acordo com o seguinte princípio: crie um projeto com uma única dependência, estabeleça dependências, após as quais o peso total da pasta é medido. Como resultado, não criei outro critério, como o número de cópias duplicadas.
Para entender qual pacote precisa ser alterado, são consideradas as razões para duplicatas, mais especificamente a origem e o efeito. A enumeração elimina os efeitos duplicados, tanto quanto possível, e, como os efeitos são eliminados, os duplicados são mais tarde.
Como resultado , obtivemos um pequeno aplicativo cli ostap que recomenda versões ideais para reduzir o número de instâncias duplicadas no pacote.
Começa apenas apontando para package.json do seu projeto.
ostap ./package.json
Você também pode usá-lo para visualizar rapidamente todas as capturas futuras sem reconstruir o projeto, alterando apenas as versões no package.json.
ostap ./package.json -s
Como resultado, no meu projeto, o peso total dos pacotes diminuiu 15%.
O repositório possui uma seção de início rápido.
Se você usar a divisão de rotas, pode parecer que alguns pacotes aumentaram de peso, mas a distribuição dos componentes pode ter mudado. Ou seja, em vez de cópias de dependências em cada página, a única versão se transformou em um pacote configurável comum para todas as páginas; portanto, é necessário avaliar o peso total dos pacotes configuráveis para todas as páginas.
Espero que o artigo tenha sido útil. E alguém economizará informações de tempo. Obrigada
Referências para conveniência novamente:
- Modelagem de pacote da árvore de dependência do pacote configurável por package.json
Github - Otimizador de Dependências para eliminar duplicatas em um pacote
Github
Se você tiver idéias interessantes, escreva para publicar no github, discutiremos isso.