Pular para o conteúdo
← lab
modelholds-upossarchitectureagents

Pare de remendar suas dependências. Seja dono do ponto de extensão.

Monkey-patches espalhados não têm versão nem como ser compartilhados. Seja dono do ponto de extensão: um override versionado no npm sobrevive a updates e converge com o upstream, sem fork barulhento.

Os patches estavam se acumulando. Uma edição no registry.js aqui, um script wrapper em /usr/local/bin/hermes-paperclip ali, um monkey-patch no hermes-execute.js que precisava ser reaplicado a cada update do upstream. Nenhum tinha repositório nem número de versão, então nenhum podia ser compartilhado.

Uma pergunta revela o problema real: quando foi que você remendou aquilo pela segunda vez?

O primeiro patch é uma gambiarra que você aceita porque entregar importa. O segundo é um sinal. Você não está mais corrigindo um bug. Está mantendo um fork privado, informalmente, sem infraestrutura nenhuma em volta.

Seja dono do ponto de extensão. Toda ferramenta madura tem um: um registry de plugins, uma interface de adapter, um hook. O upstream colocou essa costura ali por um motivo. Coloque suas mudanças nela, num pacote npm versionado, com CI e changelog. Aí elas sobrevivem aos updates do upstream, fazem deploy em vários hosts e passam por review como código, em vez de serem reconstruídas de memória depois do próximo incidente.

Foi isso que virou o @felipefontoura/paperclip-adapter-hermes-local-plus: um plugin publicado que sobrescreve o adapter nativo hermes_local pelo ponto de extensão declarado, com histórico de releases e um pipeline de CI que roda em menos de 30 segundos.

A outra metade é cidadania upstream. Assumir o ponto de extensão não significa fazer fork barulhento. Os bugs que você corrigiu no seu plugin provavelmente já têm PRs abertos no upstream. Comente neles com evidência de produção. Dê crédito a quem abriu. Se houver uma lacuna real sem PR, abra uma correção cirúrgica. O objetivo é fechar a lacuna, não manter o override para sempre.

Patches se espalham. Pontos de extensão se versionam.

Lição

Quando você remendar uma dependência pela segunda vez, pare e assuma o ponto de extensão: publique um override versionado no ponto declarado em vez de espalhar correções que você vai reaplicar para sempre.