Hacker News Reader

Comment by bmitc | Hacker News Reader

I have several side projects. While I contribute to the ups and downs, the usual dagger that grinds things to a halt is hitting some bug in an open source library or language that I don't have the ability, expertise, what have you to fix. Inevitably, the library is maintained by one person who is minimally active, despite being used by tons of people, and so I just get stuck. Software is a very frustrating endeavor. Not complaining about people's time, just the fragility of the tower of stuff software stands upon.

View on HN

You made the tower yourself, no? Not to sound snarky but by making sure that (1) you do not lock yourself into any dependency and (2) you keep the use of dependencies to a minimal you do prevent most of that pain? At least that is my opinion. As a temporary workaround (sometimes permanent) I opt for a fork, which when kept to the bare minimum is usually not more then a minor annoyance.

That’s at least my experience…

Well, the option is to rewrite the entire stack yourself. So sure, let me spend a lifetime doing that instead of things I'd like to be doing. I already opt for minimal dependencies. The problem is that every piece of software I have ever interacted with has had bugs that immediately surface, and nearly universally, there's only a handful of people that can fix them. I can't possibly be expected to reimplement or even fix projects that have taken decades to develop.

You say don't lock yourself into dependencies. Well, to create a window on an OS, you have no choice but to have a dependency, because that's how the real world works. The only option is to write your own OS, but even that has dependencies.

That's what I typically do.

I'll make sure that the libraries I rely on are either ridiculously well proven, or easily replaceable. If they are neither of those things I implement a new one myself from stuff that is, while no doubt just as buggy, it's at least code I can easily fix myself if it breaks.

Usually it's not that much work. I'll just implement what I actually need. Many open source projects are hilariously over-designed and have significant feature creep. If you cut that out you can replace the critical components with not a lot of code and not a lot of hassle.

If it can't be trivially re-implemented, I've been known to fork an existing project and take a grinder to it until it does what I want, usually axing away most of what I don't need to only expose the code I need.

This x 1,000

That's a really bad attitude. I ran into a bug in NPM that prevented our CI builds running entirely.

That NPM bug still isn't fixed (despite the bug having minor security implications), but there's no way I'm re-writing everything to not use NPM, it would be absurd, nor is it sensible to fork NPM and invest time into fixing the bug.

I ended up putting in effort to work around the bug entirely, but it was only coincidence that we could go without the feature that triggered the bug because we were going to deprecate that module anyway.

Are you really suggesting that developers don't "lock themselves in" to NPM? It's one of the most prolific projects that exists and it would be career limiting to avoid using a package manager or all dependencies entirely.

You probably already know but I found patch-package [1] to be crucial when relying on minor npm packages. It’s so freeing to be able to just fix it on your end and move on (and also raise a PR against the package)

[1] https://www.npmjs.com/package/patch-package

Thanks, but this was a bug in npm itself.

Ah my bad! Luckily I haven’t ran into one of those yet and I’m hoping I never will :p

Was the same bug in yarn?

It sounds like you have informed npm about the issue? If it is a widely faced issue, chances are that the maintainers will fix the bug. On the other hand you might be using npm in a way that is rather fringe.

You could try pnpm or yarn?

I try to sort out the dependency issue with one of the following solution (order relevant)

1) fork and fix, submit PR and use my fork until PR is not merged, if ever;

2) find replacement;

3) remove it and find workaround to implement the user feature in other way;

4) just completely abandon the feature.

What "stack" are you using for your personal projects that is both widely used but so poorly supported that a bug crops up that prevents you from forward progress? I am genuinely curious about this because I can say that I have never had that experience with something that is popular. Then again, I am an extreme minimalist when it comes to introducing 3rd party dependencies into the code that I write.

Reply on news.ycombinator.com