Stop patching your dependencies. Own the seam.
Scattered monkey-patches have no version and nowhere to share. Own the seam: a versioned npm override survives updates and converges with upstream instead of forking noisily.
The patches were piling up. A registry.js edit here, a wrapper script at
/usr/local/bin/hermes-paperclip there, a hermes-execute.js monkey-patch
that had to be reapplied after every upstream update. None had a repository or
a version number, so none could be shared.
One question reveals the real problem: when did you patch that thing a second time?
The first patch is a hack you accept because shipping matters. The second patch is a signal. You are no longer fixing a bug. You are maintaining a private fork, informally, with no infrastructure around it.
Own the seam. Every mature tool has an extension point: a plugin registry, an adapter interface, a hook. Upstream put that seam there for a reason. Put your changes there, in a versioned npm package with CI and a changelog. Then they survive upstream updates, deploy to multiple hosts, and get reviewed as code instead of reconstructed from memory after the next incident.
That is what became @felipefontoura/paperclip-adapter-hermes-local-plus: a
published plugin that overrides the built-in hermes_local adapter through the
declared extension point, with a release history and a CI pipeline that runs in
under 30 seconds.
The other half is upstream citizenship. Owning a seam does not mean forking noisily. The bugs you fixed in your plugin probably already have PRs open upstream. Comment on them with production evidence. Credit the engineers who opened them. If there is a real gap with no PR, file one surgical fix. The goal is to close the gap, not maintain the override forever.
Patches scatter. Seams version.
Takeaway
When you patch a dependency twice, stop and own the seam: publish a versioned override at the declared extension point instead of scattering fixes you will re-apply forever.