So another day, another debate at work. Life goes on as usual. This one has to do with dependencies that nearly do what you need.
Let's say you need to implement a bespoke feature but
- you don't want to reinvent the wheel
- your extensive research have shown that existing packages only do some of the things you need
What's the next course of action?
- do you pick the package that satisfies most of your requirements, fork it, adjust it to your needs and move on?
- do an MR, be patient hoping that the package is still maintained and that your fix will eventually be merged
- do you try to use the that package by hacking your way around the it, until it satisfies the requirements
- do you write everything from scratch
If you do fork it
- do you feel the need to publish it on package manager (npm, nuget etc) with a different name for the slight chance that someone else might have similar requirements?
Personally 5-6 years ago I would try to hack my way around a package trying to do what I want it to do, trusting the developer that maintains that package entirely.
But nowadays, depending on the complexity of the package, I rather fork it, add my feature/fix and move on. And most of the times I don't even consider whether the community will benefit from such bespoke (usually) features. So I don't bother publicly republishing the new package. Not to mention that who needs another variation of a package, its nearly pollution.
Top comments (0)