🍇 🍲 📶 Dependências do JavaScript do caminho para o inferno 🛵 🚐 🏯

Cada projeto JavaScript começa com boas intenções, a saber, que seus criadores prometem a si mesmos não usar muitos pacotes NPM durante seu desenvolvimento. Mas, mesmo que os desenvolvedores façam esforços consideráveis para manter essa promessa, os pacotes NPM penetram gradualmente em seus projetos. O tamanho do arquivo package.jsonaumenta com o tempo. E desde a package-lock.jsoninstalação das dependências, ocorre um verdadeiro horror, expresso em adições e exclusões de pacotes, especialmente perceptíveis no próximo PR ... "Está tudo bem", diz o líder da equipe. O resto da equipe concorda com a cabeça. O que mais fazer? Todos gostamos do fato de que o ecossistema JavaScript está vivo e bem. Não precisamos reinventar a roda todas as vezes e tentar resolver os problemas que já foram resolvidos pela comunidade de código aberto.

Suponha que você crie um blog e deseje usar o Gatsby.js. Tente adicionar este gerador de sites com base no seu projeto. Agora parabéns. Seu projeto tinha apenas 19.000 dependências adicionais. Isto é normal? Quão complexa pode uma árvore de dependência de JavaScript se tornar? Como uma árvore de dependência se transforma em inferno? Vamos descobrir.

O que é um pacote JavaScript?

O NPM (Node Package Manager, Node Package Manager) armazena o maior registro de pacotes do mundo. Estes são pacotes JavaScript. O NPM é mais do que RubyGems, PyPi e Maven combinados. Essa conclusão pode ser feita com base na análise dos dados do projeto Module Counts , que monitora o número de pacotes nos registros populares.

Dados sobre o número de pacotes em registros populares

Você pode pensar que quantidades muito grandes de código estão representadas neste gráfico. Do jeito que é. Para transformar um projeto em um pacote NPM, este pacote deve ter um arquivopackage.json. Esse pacote pode ser enviado ao registro do NPM.

O que é o package.json?

Aqui estão as tarefas que ele resolve package.json:

Ele lista os pacotes dos quais seu projeto depende (esta é uma lista de dependências do projeto).
Nele, usando as regras do controle de versão semântico, são definidas as versões dos pacotes de dependência que seu projeto pode usar.
Permite reproduzir o ambiente necessário para o pacote funcionar e, como resultado, simplifica a transferência do projeto para outros desenvolvedores.

Um arquivo package.jsonpode ser pensado como um arquivo READMEbombeado com esteróides. Aqui você pode descrever as dependências do seu pacote, aqui você pode escrever scripts que são executados durante a montagem e teste do projeto. O mesmo arquivo contém informações sobre a versão do projeto especificada pelo desenvolvedor e uma descrição do projeto. Estamos particularmente interessados na possibilidade package.jsonde especificar dependências do projeto.

Talvez o fato de as dependências do projeto estarem indicadas neste arquivo pareça um tanto alarmante. Imagine que existe um pacote que depende de outro pacote e esse outro pacote depende de outro pacote. Essa cadeia de dependências pode ser arbitrariamente longa. Por esse motivo, instalar o único pacote, Gatsby.js, significa equipar o projeto com 19.000 dependências adicionais.

Tipos de dependência em package.json

Para entender melhor como as listas de dependências do projeto crescem com o tempo, vamos falar sobre os diferentes tipos de dependências que um projeto pode ter. Nomeadamente, package.jsonpodem ser encontradas as seguintes seções que descrevem várias dependências:

dependencies - são dependências comuns, cuja funcionalidade é usada no projeto e que é acessada a partir de seu código.
devDependencies- estas são dependências de desenvolvimento. Por exemplo, a biblioteca mais bonita usada para formatar o código.
peerDependencies - se as dependências forem gravadas nesta seção, o desenvolvedor do pacote informará quem irá instalá-lo que precisará de uma versão específica do pacote especificado nesta seção.
optionalDependencies - eles listam dependências opcionais, como a incapacidade de instalar, que não violará o processo de instalação do pacote.
bundledDependencies — , . , NPM, , .

package-lock.json

Todos sabemos que o arquivo package-lock.json, no decorrer do trabalho no projeto, passa constantemente por mudanças. Algo é removido, algo é adicionado a ele. Isso é especialmente perceptível ao exibir o PR que contém uma versão atualizada desse arquivo. Muitas vezes tomamos isso como garantido. Um arquivo é package-lock.jsongerado automaticamente sempre que um arquivo package.jsonou pasta é alterado node_modules. Isso permite manter o conteúdo da árvore de dependências exatamente como era quando você instalou as dependências do projeto. Isso permite, ao instalar o projeto, reproduzir a árvore de dependência. Isso resolve o problema de ter diferentes versões do mesmo pacote de diferentes desenvolvedores.

Considere um projeto cujas dependências incluem React. A entrada correspondente está disponível em package.json. Se você olhar para o arquivopackage-lock.json deste projeto, você poderá ver algo como o seguinte:

    "react": {
      "version": "16.13.0",
      "resolved": "https://registry.npmjs.org/react/-/react-16.13.0.tgz",
      "integrity": "sha512-TSavZz2iSLkq5/oiE7gnFzmURKZMltmi193rm5HEoUDAXpzT9Kzw6oNZnGoai/4+fUnm7FqS5dwgUL34TujcWQ==",
      "requires": {
        "loose-envify": "^1.1.0",
        "object-assign": "^4.1.1",
        "prop-types": "^15.6.2"
      }
    }

Um arquivo package-lock.jsoné uma grande lista de dependências do projeto. Aqui estão as versões de dependência, caminhos (URIs) para os módulos, hashes usados para verificar a integridade do módulo e os pacotes necessários para este módulo. Se você ler este arquivo, poderá encontrar registros de todos os pacotes que o React precisa. É aqui que está o verdadeiro inferno das dependências. Tudo o que o projeto precisa está descrito aqui.

Compreendendo as dependências do Gatsby.js

Como é que, tendo estabelecido apenas uma dependência, adicionamos até 19.000 dependências ao projeto? É tudo sobre dependências de dependência. É por isso que temos o que temos:

$ npm install --save gatsby

...

+ gatsby@2.19.28
added 1 package from 1 contributor, removed 9 packages, updated 10 packages and audited 19001 packages in 40.382s

Se você procurar package.json, poderá encontrar apenas uma dependência. Mas se você observar package-lock.json, acontece que diante de nós há um monstro de quase 14 kilobytes. Uma resposta mais detalhada sobre o significado de todas essas linhas de código que package-lock.jsonpodem ser encontradas no arquivo package.jsonno repositório Gatsby.js . Existem muitas dependências diretas, ou seja, de acordo com os cálculos da NPM , 132. Se cada uma dessas dependências tiver pelo menos mais uma dependência, o número total de dependências do projeto duplicará - e haverá 264 dependências. Claro que, no mundo real, não é assim. Cada dependência direta do projeto possui mais de uma dependência inerente. Como resultado, a lista de dependências do projeto é muito longa.

Por exemplo, teremos interesse em quantas vezes a biblioteca lodash é usada como dependência para outros pacotes :

$ npm ls lodash
example-js-package@1.0.0
└─┬ gatsby@2.19.28
  ├─┬ @babel/core@7.8.6
  │ ├─┬ @babel/generator@7.8.6
  │ │ └── lodash@4.17.15  deduped
  │ ├─┬ @babel/types@7.8.6
  │ │ └── lodash@4.17.15  deduped
  │ └── lodash@4.17.15  deduped
  ├─┬ @babel/traverse@7.8.6
  │ └── lodash@4.17.15  deduped
  ├─┬ @typescript-eslint/parser@2.22.0
  │ └─┬ @typescript-eslint/typescript-estree@2.22.0
  │   └── lodash@4.17.15  deduped
  ├─┬ babel-preset-gatsby@0.2.29
  │ └─┬ @babel/preset-env@7.8.6
  │   ├─┬ @babel/plugin-transform-block-scoping@7.8.3
  │   │ └── lodash@4.17.15  deduped
  │   ├─┬ @babel/plugin-transform-classes@7.8.6
  │   │ └─┬ @babel/helper-define-map@7.8.3
  │   │   └── lodash@4.17.15  deduped
  │   ├─┬ @babel/plugin-transform-modules-amd@7.8.3
  │   │ └─┬ @babel/helper-module-transforms@7.8.6
  │   │   └── lodash@4.17.15  deduped
  │   └─┬ @babel/plugin-transform-sticky-regex@7.8.3
  │     └─┬ @babel/helper-regex@7.8.3
  │       └── lodash@4.17.15  deduped
  ...

Felizmente, a maioria dessas dependências é representada pela mesma versão do lodash. E com essa abordagem, node_moduleshaverá apenas uma pasta da biblioteca lodash. É verdade que esse geralmente não é o caso. Às vezes, pacotes diferentes precisam de versões diferentes do mesmo pacote. É por isso que muitas piadas apareceram sobre o tamanho enorme da pasta node_modules. No nosso caso, no entanto, nem tudo é tão ruim:

$ du -sh node_modules
200M    node_modules

200 megabytes não é tão ruim. Vi como o tamanho desta pasta atinge facilmente 700 MB. Se você estiver interessado em aprender quais módulos ocupam mais espaço, execute o seguinte comando:

$ du -sh ./node_modules/* | sort -nr | grep '\dM.*'
 17M    ./node_modules/rxjs
8.4M    ./node_modules/@types
7.4M    ./node_modules/core-js
6.8M    ./node_modules/@babel
5.4M    ./node_modules/gatsby
5.2M    ./node_modules/eslint
4.8M    ./node_modules/lodash
3.6M    ./node_modules/graphql-compose
3.6M    ./node_modules/@typescript-eslint
3.5M    ./node_modules/webpack
3.4M    ./node_modules/moment
3.3M    ./node_modules/webpack-dev-server
3.2M    ./node_modules/caniuse-lite
3.1M    ./node_modules/graphql
...

Sim, o rxjs é um pacote insidioso.

Aqui está um comando simples que ajuda a reduzir o tamanho da pasta node_modulese simplificar sua estrutura:

$ npm dedup
moved 1 package and audited 18701 packages in 4.622s

51 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Durante a desduplicação, o npm tenta simplificar a estrutura da árvore de dependências localizando as dependências usadas por outras dependências e movendo-as para que possam ser compartilhadas. Isso se aplica ao nosso exemplo de lodash. Muitos pacotes são usados lodash @4.17.15, como resultado, para garantir sua operacionalidade, basta instalar esta versão da biblioteca apenas uma vez. Obviamente, essa é a situação em que entramos desde o início, apenas estabelecendo dependências. Se, no processo de trabalho em um projeto, package.jsonadicionar novas dependências, às vezes é recomendável lembrar a equipe npm dedup. Se você usar o gerenciador de pacotes do yarn, um comando semelhante será semelhante ao do yarn dedupe. Mas, de fato, não há necessidade, pois a otimização de dependência é realizada automaticamente quando o comando é executado yarn install.

Visualização de Dependências

Interessado em uma representação gráfica das dependências do seu projeto? Nesse caso, você pode criar uma apresentação usando ferramentas especiais. Vamos considerar alguns deles.

A seguir, é apresentado um resultado de visualização de dependência obtido em npm.anvaka.com/ .

Visualização de dependência usando npm.anvaka.com

Aqui você pode ver as dependências das dependências do pacote de projeto Gatsby.js. O resultado é semelhante a uma enorme web. O projeto Gatsby.js tem tantas dependências que essa "web" quase "travou" meu navegador. Agora , se estiver interessado, um link para este diagrama. Pode ser apresentado em forma 3D.

Aqui está uma visualização feita usando o npm.broofa.com .

Um fragmento de uma visualização de dependência feita usando o npm.broofa.com

É semelhante a um fluxograma. Ela, para o Gatsby.js, acaba sendo muito complicada. Você pode dar uma olhada aqui . Elementos do circuito podem ser coloridas com base em estimativas de npms.io . Você pode enviar seu próprio arquivo para o sitepackage.json.

A ferramenta Package Phobia permite descobrir quanto espaço ele precisa antes de instalar um pacote.

Informações sobre o pacote recebidas usando a fobia do pacote

Aqui você pode descobrir sobre o tamanho do pacote publicado e quanto espaço em disco será necessário após a instalação.

Conclusão: com grande poder vem grande responsabilidade

No final, quero dizer que JavaScript e NPM são ótimas ferramentas. O bom é que os desenvolvedores modernos têm a oportunidade de usar um conjunto enorme de dependências. Executar o comando npm installpara evitar que você escreva algumas linhas de código é tão fácil que às vezes esquecemos as consequências.

Agora que você leu até esse ponto, deve ter um entendimento mais completo dos recursos da estrutura da árvore de dependência do npm-project. Se você adicionar uma biblioteca ao projeto que é muito grande ou apenas explorar as dependências do seu projeto, sempre poderá tirar proveito do que discutimos aqui e analisar as dependências.

Queridos leitores! Deseja usar o menor número possível de dependências em seus projetos npm?

Dependências do JavaScript do caminho para o inferno