Selecionando as Dependências Certas: Um Guia Prático Abrangente

Se você fosse o chef de um restaurante sofisticado com estrela Michelin, compraria legumes e carne de fontes aleatórias não verificadas? O custo de quase qualquer projeto médio é medido em centenas de milhares ou mesmo milhões de dólares. Acredito que nossa indústria deveria ter a mesma abordagem dos restaurantes.

A primeira pergunta a se fazer desde já: você realmente precisa de uma nova dependência? O problema poderia ser resolvido usando o ambiente atual, como o idioma ou as bibliotecas instaladas? Por exemplo, não há necessidade de instalar uma biblioteca adicional para gerar UUIDs. Node.js e navegadores oferecem suporte imediato: crypto.randomUUID()

A segunda pergunta: você precisa de toda a biblioteca? Por exemplo, se você só precisa de um menu suspenso, vale a pena instalar algo como o Bootstrap? Talvez seja melhor limitar-se a uma única biblioteca focada com um componente suspenso sem estilo do Radix UI ?

OK. Temos alguns candidatos em mente. Então, como podemos escolher o caminho certo?

Um README lindamente formatado? Um nome conhecido? Mais garfos, estrelas e downloads do que outros? Infelizmente, esses fatores por si só não são suficientes. Aqui, estamos selecionando um provedor de serviços. Queremos que os problemas que surjam sejam resolvidos rapidamente, que as funcionalidades se mantenham atualizadas e, acima de tudo, que o serviço seja seguro e confiável. Métricas externas simples nem sempre indicam a qualidade ou adequação a longo prazo. Antes de instalar o que encontramos no catálogo do repositório, seria bom visitar o repositório GitHub e analisar seu conteúdo.

Eu preparei uma lista de critérios que tenho usado nos últimos anos. Espero que eles ajudem você a escolher as bibliotecas mais adequadas. É essencial considerá-los de forma abrangente e, em alguns casos, fazer concessões ao escolher entre eles.

Isenção de responsabilidade: não estou criticando as bibliotecas mencionadas abaixo ou tentando desencorajar seu uso. Em alguns casos, omiti nomes intencionalmente para focar no exemplo de critério, mantendo a precisão factual.

1. Segurança

Quão seguro é usar? Pode parecer ficção, mas sim, as dependências podem ser perigosas. Por exemplo, um recurso interessante foi adicionado a uma biblioteca com 500 mil downloads: ele tenta substituir todos os arquivos do computador por ❤️ se o seu endereço IP estiver dentro de um intervalo específico.

Um fato interessante é que essa dependência foi usada no vue-cli . Como podemos descobrir tais problemas? Verifique a página de problemas ou tente pesquisar no Google pelo nome da biblioteca. Normalmente, essas informações surgem rapidamente.

2. Manutenção

Quando foi o último lançamento? Com que frequência ocorrem os lançamentos? As versões regulares garantem que os problemas sejam resolvidos e as atualizações suportam tecnologias em constante mudança. No contexto do desenvolvimento móvel, os lançamentos regulares também garantem que o projeto seja compilado com sucesso.

Aqui está um exemplo do mundo do Go: os autores de uma biblioteca com 18,2 mil estrelas decidiram parar de manter sua dependência e a arquivaram. Isso significa que, em alguns anos, a falta de suporte e atualizações se tornará um problema. Agora imagine instalar uma dependência semelhante sem verificar primeiro o GitHub. É uma espécie de verificação da data de validade dos produtos.

Aqui está um exemplo de bons lançamentos frequentes:

3. Questões Abertas/Fechadas

1. Qual é a proporção de questões abertas para questões fechadas? Até que ponto os autores estão dispostos a aceitar mudanças? É possível que você precise contribuir com algo algum dia. Por exemplo, esta biblioteca é bastante popular e tem uma porcentagem de 98% de problemas fechados. Apenas 18 estão abertos.

   

   
   

2. Com que rapidez os problemas críticos são resolvidos? Uma vez escolhi um ORM com 31k estrelas, mas em algum momento nos deparamos com um problema que nos bloqueou. Tivemos que procurar soluções alternativas e, eventualmente, mudar para outra solução. Infelizmente, quase quatro anos se passaram e o problema ainda não foi resolvido.

   

   Tais problemas podem ser identificados classificando pelos mais comentados.

   
   

3. O processo de contribuição foi organizado pelos criadores? Existe um fluxo de trabalho claro e definido? Por exemplo, os criadores do Next.js gravaram um vídeo de 40 minutos sobre o processo de contribuição.

   
   

4. Qualidade do Código

Sim, pode haver muito código, mas sempre é possível examinar suas diferentes partes. Como o projeto está organizado? É compreensível e bem estruturado, e as boas práticas se aplicam? Quanto pior o código for escrito, maior a probabilidade do fim do projeto no futuro. Muitos pequenos candidatos foram eliminados nesta fase para mim.

5. Cobertura de teste

A biblioteca tem testes? Qual é a cobertura do teste? Como os testes foram escritos? Mesmo que os mantenedores revisem as solicitações de mesclagem, há uma chance de algo passar despercebido. Há muitas pessoas diferentes que contribuem para a biblioteca. Normalmente, as informações de cobertura de teste são exibidas em crachás na parte superior do repositório. Porém, se não for, podemos sempre buscar testes no projeto. Por exemplo, a família de bibliotecas formatjs possui excelente cobertura de teste e inclui vários tipos de testes.

6. Tamanho da biblioteca

Os aplicativos móveis geralmente têm grandes tamanhos de dependência e o aplicativo inteiro pode ter mais de 200 MB, o que pode causar problemas durante os downloads da rede celular e consumir muito espaço de armazenamento. Isso é especialmente problemático para aplicativos CSR front-end, em que velocidades lentas da Internet podem aumentar drasticamente os tempos de carregamento.

Para projetos da web, existe uma ótima ferramenta para determinar o tamanho dos pacotes: https://bundlephobia.com . Obviamente, a renderização do lado do servidor e a trepidação da árvore podem reduzir o tamanho, mas isso precisa ser sempre verificado.

Um exemplo popular são as bibliotecas de manipulação de datas. A funcionalidade fornecida por dayjs (2,9 KB) pode ser suficiente, eliminando a necessidade de instalar moment.js (72,1 KB) ou date-fns (26,8 KB).

7. Número de Dependências

Todos os pontos listados acima são multiplicados, até certo ponto, pelo número de dependências em toda a árvore de dependências do projeto. Uma ótima ferramenta para verificar a árvore de dependências completa: https://npm.anvaka.com

8. Licença

Você já pensou sobre isso? Eu também não. Por exemplo, as licenças MIT e Apache 2.0 permitem o uso gratuito de bibliotecas em projetos comerciais, enquanto algumas licenças GPL v2 possuem requisitos e restrições específicos. Em um de nossos projetos, tínhamos uma tabela preparada por um advogado para verificar todas as licenças da nossa árvore de dependências. Portanto, se você perceber algo incomum em uma licença, é melhor consultar um advogado para evitar problemas durante uma auditoria. Podemos extrair todas as licenças das dependências npm existentes usando o utilitário legalmente . PS Não sou advogado e isso não foi um conselho jurídico. É um caso raro e especializado que algo pode não ser adequado devido à licença, mas ainda é possível.

O fim!

Obrigado por ler o meu artigo! O ponto principal foi mostrar exemplos do mundo real de que tomadas de decisão superficiais e rápidas às vezes podem não levar à melhor opção. Ao considerar esses critérios, você poderá tomar uma decisão mais informada.

Por favor, sinta-se livre para deixar quaisquer comentários ou sugestões que você possa ter. Não hesite em compartilhar sua experiência nos comentários também. Suas curtidas e comentários me inspiram a escrever novos artigos. Cozinha feliz :)