Hacker News Reader

Comment by zozbot234 | Hacker News Reader

> Sometimes you just say fork it.

FTFY. And vendoring a dependency is really just a hidden fork.

That raises the question: what is the current etiquette around deciding whether to pester a dependency's author to include your fixes or just fork it, especially if it looks like you will be the biggest user of that dependency? I'm dealing with that question for a dependency that I want to introduce in one of my crates, but ideally not until at least one of my own fixes is merged.

My thought process is:

1. You find a bug, open an issue. 2. If bug is a minor issue, wait. If I want a fix really bad, offer to fix it. 3. If I still want a fix really bad and author did not respond, or does not want a fix, then fork the project for my own consumption. Using alternative dependencies are also an option.

Yup, and forks don't have to be permanent.

Imo be ready to fork all the things if need be. Get comfortable with it before you're forced to.

In my opinion, you should always ask the author first. Having your changes accessible from the primary repository is much easier and better for everyone, and there is a good chance the author is happy to accept your PRs. On the other hand, they might not agree with your proposal or might want to make significant changes to the design, at which point it becomes a personal tradeoff for you.

Obviously fork it, implement your feature, battle-test it, fix and make it more generic, battle-test it again, then ask the maintainer if they would be interested in a pull request.

I mean, implementing your fixes in the first place means you are already inherently forking it.

> FTFY. And vendoring a dependency is really just a hidden fork.

It's not a fork until you start diverging from upstream with local modifications.

Reply on news.ycombinator.com