Hacker News new | ask | show | jobs
by gdcbe 1268 days ago
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…

3 comments

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.

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
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?
Was the same bug in yarn?
This x 1,000