Existe alguns pontos que eu acho problemáticos ao se adotar uma dependência (lib, framework,...)

Pelo hype

Como diriam os titãs: a melhor banda de todos os tempos da última semana
Todo dia surgem ferramentas milagrosas, resolvedoras de todos os males. Porém ninguém realmente testou essas ferramentas em produção por muito tempo, e já tem gente colocando em projetos reais.

Fazer isso é anti-profissional

Sem entender se o projeto/problema realmente precisa de uma solução desse tipo

Usando React como exemplo, tem muito site por aí que não precisava de React. Normalmente o programador adotou React por ser a única coisa que ele se propôs a estudar, e pulou os estudos de conceitos.

Já vi alguns projetos usando React apenas para validar formulários, gente... A validação nativa de formulários do HTML que está disponível há anos, já dá conta de boa parte do recado.

Sem entender como a dependência funciona

A pessoa nunca nem viu a dependência funcionando, não leu a documentação, não fez uma PoC. Apenas dá um npm install ... (composer, cargo, pip, etc), e reza para funcionar.

Sem se preocupar se o projeto é bem mantido pela empresa ou comunidade por trás dessa dependência

Além de projetos, já vi até tutoriais apresentando o uso de libs que já não são mais mantidas há muito tempo. Como o silex sem manutenção há 6 anos.

O silex era muito usado para criar rotas no PHP, esse tipo de projeto causa uma forte dependência do seu projeto com a lib, imagina o quão frágil é um projeto usando silex hoje em dia. Além desse forte acoplamento, não deixar seu projeto ser atualizado para novas versões do PHP nesse caso.

Sem dominar a linguagem por trás dessa dependência

Isso é o principal ponto de falha na minha opinião, se você não tem o mínimo de domínio na linguagem base, como você saberia dizer que um erro no projeto é por conta da lib ou por conta do seu código?

Já peguei um bug de um projeto em que a lib utilizada não realizava o clearInterval quando necessário. Perguntei ao programador original do projeto se ele não tinha visto, e por incrível que pareça ele não sabia o que era clearInterval. Típico programador frontend, mas desde que o frontend seja restrito ao framework X.

Quando é uma boa ideia usar dependências externas

Uma vez superado os pontos descritos acima, dependências externas são realmente uma boa ideia para agilizar a entrega.

Não há motivo para se recriar o ExpressJS se ele atende muito bem a necessidade do projeto.

Mas cuidado com a preguiça, dois exemplos clássicos são:

• is-odd com mais de 460k instalações nessa semana
• is-even com quase 300k instalações nessa semana

A primeira retorna se um número é ímpar, a segunda retorna se o número é par. 🤡🤡🤡

Ou seja, fazem o mesmo que (n % 2) === 0 e (n % 2) !== 0. Precisa mesmo dessa dependência no projeto?
Pela quantidade de instalações na semana, tem gente que pensa que sim, são UMA VERGONHA PARA A PROFISSION

Cada caso é um caso. Eu sou o tipo de programador que pensa um milhão de vezes antes de instalar uma lib. Meu critérios são:

1 - eu realmente preciso? Vou instalar essa lib pra não "reinventar a roda" ou por pura preguiça(Left Pad por exemplo)?

No seu caso, acho mais inteligente instalar um lib para o carrossel. Não é algo tão simples quanto parece, logo também não é algo crítico que vá quebrar o software, ao meu ver. Agora, se você for instalar uma lib para descobrir se um número é par ou impar, dai é preguiça pura.

2 - se eu preciso de uma lib, então vou procurar uma que seja estável, bem implementanda, conhecida, segura, que tenha manutenções frequentes e que tenha um licença adequada para seu uso.

O que tem de libs por ai nessa selva JS cheias de malwares é coisa de doido. Entre no repositório da lib e veja se tem uma alma viva que cuide dele e que não seja um projeto abandonado, com commits de 2 anos atrás.

3 - se quiser, seja curioso! Entenda como a lib funciona e tente implementar a sua própria! Isso separa os bons programadores dos medíocres.

Como disse, não gosto de ir instalando um monte de pacotes sem motivo. Tento deixar meus projetos o mais simples possível. Quanto mais libs, mais chances de quebrar. Pode ser ágil agora, mas lá pra frente vai ser o triplo de dor de cabeça!

Sobre algumas dependencias especificas que foram levantas nas outras já execlentes respotas:

Express

No desenvolvimento web com Node.js, o Express.js se destaca como uma extensão quase natural, semelhante à relação entre C++ e Boost. A questão não é a necessidade reinventar o Express, mas como proceder quando enfrentamos limitações ou problemas com ele.

A inclinação natural pode ser buscar soluções prontas, construídas sobre o próprio Express. No entanto, antes de adicionar outra dependência ao seu projeto, considere explorar as abstrações de rede nativas do Node.js. A solução mais eficaz e segura pode ser alcançada com o que já está disponível na plataforma, sem a necessidade de introduzir mais uma biblioteca externa.

is-odd

Se o Node oferecesse tal função nativamente, usá-la não apresentaria problemas. O real perigo está em adicionar ao projeto pacotes aleatórios do npm que, apesar de populares, podem carregar vulnerabilidades severas. O simples ato de instalar uma biblioteca com alertas de segurança deveria ser um sinal vermelho, mas muitas vezes é ignorado.

Na teoria, a melhor prática seria inspecionar e entender cada linha de código de terceiros que você inclui no seu projeto. Embora isso possa ser impraticável esse princípio não deve ser descartado. Esforçar-se para compreender o funcionamento e as implicações de segurança dos pacotes de terceiros não pode ser negligênciado.

A gestão prudente das dependências externas é um pilar fundamental para a segurança e manutenção de qualquer software no longo prazo. Esse cuidado não apenas protege seu projeto contra vulnerabilidades e erros desconhecidos, mas facilita o processo de atualização e manutenção, tornando-o mais gerenciável a longo prazo.

Carrossel

Se uma biblioteca de UI que você já utiliza em seu projeto oferece um carrossel que atende às suas necessidades, aproveite essa funcionalidade. Por outro lado se o objetivo é criar uma solução personalizada, recorrer a uma "colcha de retalhos" de bibliotecas aleatórias não é uma abordagem razoável. Nesses casos, desenvolver sua própria solução, torna-se uma escolha mais acertada.

Se o seu projeto já está utilizando um framework, como React, faz sentido aproveitar as capacidades para desenvolver componentes adicionais, como o carrossel. Agora introduzir uma lib como o react apenas para implementar esta funcionalidade também não é razoável. A solução para um novo requisito deve ser construída a partir do que você já tem, combinado com implementação própria que atenda especificamente às suas necessidades.

---

Software de terceiros, mesmo que aberto e gratuito, traz consigo um custo implícito. Antes de adotar, é essencial considerar se o esforço de criar algo não superam estes custos implícito no longo prazo.

O "molho" do seu projeto, especialmente aqueles aspectos que definem sua proposta de valor e diferencial competitivo, deve permanecer sob seu controle direto. Dependender excessivamente de terceiros para funções centrais vai colocar seu projeto em risco catastrófico se essas dependências falharem.

O mal entendio do não reinventar a roda

Se não existem rodas para seu carro disponíveis no mercado, a solução é fabricar a sua própria. Isso não significa reinventar a roda: você enfrenta o mesmo problema – a necessidade de movimento – e reconhece que uma roda é a solução adequada. Agora, o passo seguinte é construir essa roda, uma que se ajuste perfeitamente ao seu fusquinha mequetrefe e não tentar colocar uma roda de Ferrari nele.

Compreenda (estudando as soluções testadas e provadas) a solução geral do problema: a "roda": e então construa uma versão que se adeque exatamente ao seu contexto.