Primeiros socorros para dependências JavaScript avariadas

Gostaria de escrever sobre JavaScript dependências. Mas vamos começar pelo princípio. Se é um programador de software, provavelmente já sabe que uma das suas muitas funções não é, definitivamente, ser mais um inventor de rodas. Pelo menos, não na maioria dos casos. O mundo já avançou o suficiente para dizer que atualmente existem pacotes para quase tudo, tornando o nosso desenvolvimento mais fácil e eficiente.

É claro que isto não é um incentivo para perder o interesse noutras questões - cada pacote tem um espaço bastante grande para melhorar e evoluir. No entanto, o seu objetivo comercial é oferecer um serviço completo de produto num prato mesmo a tempo ou mesmo antes de estar pronto. Os pacotes ajudá-lo-ão a cumprir esses planos, trazendo npm ou fio no topo da lista dos seus melhores amigos, mas atenção: qualquer solução, tal como esta, também pode trazer riscos. Vamos tentar descrevê-lo e mostrar-lhe uma melhor forma de o evitar no artigo que se segue.

Vamos começar com uma história...

Imagine um grande JavaScript projeto. Os requisitos comerciais obrigam os programadores a utilizar um pacote específico, permitindo uma integração adequada com outro sistema de um cliente. E isso é perfeitamente correto. MVP foi entregue atempadamente, o contrato seguinte foi assinado e o desenvolvimento prossegue. O cliente pede para integrar a parte seguinte de um sistema, o que requer a atualização do seu pacote.

Esta parte corre bem, até que os testes são efectuados. Parece que o pacote contém um bug simples, mas inconveniente, que ainda não foi corrigido em nenhuma versão do produto e sabe-se que isso não acontecerá tão cedo. Não se pode simplesmente corrigir o módulos_nó diretório - ele deve ser removido do seu repositório de rastreamento, portanto seus colaboradores nunca saberão nada sobre suas mudanças! Bem, enquanto estava a ler isto, provavelmente já percebeu o que fazer - fork. Mas será que precisa mesmo de um martelo destes?

Compreender o seu problema

Deve ter em atenção se o problema com que se depara vai envolver apenas o utilizador ou uma comunidade maior. Por vezes, as pessoas interpretam a falta de uma determinada funcionalidade como um erro, o que nem sempre é correto. Por conseguinte, a sua solução pode não ser aceite por uma comunidade e não ser incluída num repositório oficial. No entanto, continua a precisar dele aqui e agora. Então, vamos remendá-lo!

De acordo com as notas de lançamento do repositório github, o patch-package ) foi lançado oficialmente em maio de 2017. It é uma ferramenta poderosa, que permite que as modificações dentro do projeto de dependência sejam instaladas no seu módulos_nó diretório. Alguns poderão dizer que isto é uma loucura - ao disparar o comando de instalação, o seu gestor de dependências irá substituir as alterações.

Bem, isto está correto. No entanto, um patch-package coexiste com npm e fio perfeitamente (devo admitir que funciona um pouco melhor com o npm até agora, pode ler mais na secção "Porque deve usar o postinstall-prepare com o Yarn?" do ficheiro README) e tira o máximo partido de uma preparação de script ("script": { "prepare":""}) do seu package.json ficheiro. O patch-package cria literalmente um diretório de diferenças entre as suas alterações e o pacote original, armazenado na pasta de patches do seu projeto atual.

Depois de executar o comando install e descarregar todas as dependências, aplica essa diferença ao diretório do projeto, fazendo uma reconstrução perfeita das suas alterações para todos os colaboradores. Torna a sua vida mais simples, não é? A solução também tem algumas desvantagens. O patch-package não pode corrigir as dependências do seu pacote ou fazer qualquer alteração no package.json.

Neste caso, pode utilizar a solução de bifurcação. Além disso, deve considerar o número de alterações que está prestes a aplicar no seu pacote de dependências e se estas irão aumentar com o tempo. No caso de irem - deve pensar cuidadosamente quando utilizar o fork, uma vez que este é um projeto seu.

Não sejas egoísta!

Patching é uma ótima maneira de corrigir suas dependências sem criar forks intermináveis e gerar múltiplos fontes de projeto. Mas deve sempre lembrar-se que tirar partido da comunidade não deve ser unidirecional. Se encontrar um erro ou sentir que pode melhorar o pacote que está a utilizar, deve sempre considerar a possibilidade de ajudar os outros, registando um problema ou mesmo contribuindo para o projeto!