3 ms·
I have a question for you all: When you're building something and you notice one of your dependencies has a bug or is missing a key feature that you need, do y
by lhnz 3y ago
I have a question for you all:
When you're building something and you notice one of your dependencies has a bug or is missing a key feature that you need, do you (a) PR the fix into the dependency and then try to "harrass" the maintainer into merging it for you, (b) publish your own fork of the dependency with the necessary fix, (c) inline the source code for the dependency into your project, effectively taking it on as if it's your own code, (d) completely rewrite the dependency either as a separate package you control or built directly into your own project, or (e) code around the problem / do a hack?
I find that often maintainers are so over-worked that it's practically impossible to get a merge in a timely manner, and this leads me to rely on a fork until the PR eventually gets merged. However, I think creating a new package under either your own ownership or the company you work for is often really bad as it can become a kind of hidden technical debt. Nowadays, I definitely consider inlining as a way to capture ownership of the technical debt in a way that is highly visible, but this can add 100s or 1000s of lines of code to a project and if eventually the upstream project moves on you don't get the benefits of their changes without removing the inlined code and untangling any changes that were made to it.
The only other approach I've seen is the 'hack' approach, in which you try to dodge the bug or semantic issue. Honestly, that might be the right thing to do in some situations, but it isn't very hygienic within a long-term project (unless you carefully maintain a TODO list of things that need 'correct' solutions).
- alexaholic 3y agoOn a reasonably large project, you accumulate sufficient dependencies that you end up doing all of that.
- lategloriousgnu 3y agoWe patch our dependencies. This adds a diff to your repo, not an entire fork of the dependency. A package manager like pnpm will install the package as usual, then apply your patch over the top. https://pnpm.io/cli/patch https://pnpm.io/cli/patch
- lhnz 3y agoYes, good shout -- I do this sometimes, too. The only thing is that it doesn't work if what you're releasing is a shared package or installable and is not part of an application.
- jansommer 3y agoYou might as well assume (c) whenever you use a library provided free of charge. Be prepared to either fix the bugs yourself or make sure there are alternatives you can use as a replacement. Even if the author is responsive now, there's no guarantee you'll get help once your code is in production a few months later. The library might even be archived at that point. Lets say you've used FFTS, the Fastest Fourier Transform in the South [0]. Performance is spectacular, but now it's no longer supported and you find a bug. The code is impressive: Thousands of lines of code that dynamically generate SIMD instructions. But it's impossible to understand. You have chosen a library you cannot repair yourself. This is fine when there's alternatives, and there are for FFTs, and they are easy to swap out. If you can't easily swap out one library with another, you better make sure that you can repair it yourself. And I hope people don't harass or "harass" library authors into merging pull requests... [0] https://github.com/anthonix/ffts https://github.com/anthonix/ffts