Hacker News Reader

Comment by yoz-y | Hacker News Reader

What I’d like is a utility library like this, but instead of it being an actual library, be it some utility that generates a single file with exports of the few functions I need. Even just something that would make copy pasting them easier.

As in, I want actual zero dependencies, not even the library itself. The reason: I never want these to randomly update.

View on HN

Couldn't you just pin a specific version dependency? My brain says there's some way to also pin to a hash, but that would require googling and I'm on mobile.

The problem is that even if you pin to a version, at some point you’ll need to update node, typescript, or some other package, and then if this package doesn’t update, then you may have to migrate from it to something else. While js tries to enforce backwards compatibility, and npm, etc. help with the complex landscape, in practice with node, typescript, etc., even with LLMs helping, it can be a pita and hours or days of work to update at times. It’s just not worth it for things you could’ve just implemented yourself. There are exceptions to this, though.

> at some point you’ll need to update node, typescript, or some other package

I experienced both sides of this discussion (project that always pulled :latest disregarding any kind of versioning, and project that had node_modules commited inside the repo) and both extremes suck, but I lean towards the second one. I'll totally take a few days of pain over not knowing whether prod will work today or not.

This is why running your own mirror is what most large companies do. Guarantee no take-backs.

Pinning is a good strategy (I'd say that it should be the default one), but depending on your level of paranoia (think left-pad), you might consider just downloading the lib as it is, and storing it in source control forever.

I do sort of miss bower [0] for this reason. It was really just a way to download javascript and plunk it into your application. It was standard practice to check all of your vendor dependencies into SCM. [1] Of course a good chunk of it was transformed through something like Gulp or Grunt before being added to the bower repository so you were unlikely to maintain those once checked in, but there was still quite a few packages (small jquery image gallery plugins and the like) that were just some un-transformed javascript someone typed up and threw at bower verbatim.

[0] https://bower.io

[1] https://addyosmani.com/blog/checking-in-front-end-dependenci...

Nobody wants anything _ever_ to ”randomly update”. Why this is the default setting on so many development setups boggles my mind.

I really havent figured out why professional systems insist running on the bleeding edge - it’s your feet are bleeding here I believe. 10 year … 15 year old code is generally excellent if you know it through and thorough.

As my experience grows, I'm getting fonder of stances like Debian or Common Lisp, which favors stability. Once you've solved a problem, it's not fun having your foundation morphs under you for no other reasons than bundling features and security updates.

CVEs are a thing. If vulnerabilities are discovered in your dependency graph, choosing to ignore them can have severe consequences.

I don’t believe anything I wrote above promotes the idea of ignoring vulnerabilities as a standard procedure.

CVE database is an excellent way to be informed about vulnerabilities and there are services to automatically map CVE reports to code bases.

Ok, but the context for the conversation is external dependencies, and you expressed a preference for code aged 10-15 years. I'm just saying that a codebase that's 10-15 years old, with any dependencies at all, is going to be rife with vulnerabilities. Thus the choice is either staying current or living with vulnerabilities.

What's the alternative? Are you suggesting that backpatching transitive deps dating back over a decade-plus tineframe is a viable maintenance strategy?

I'm suggesting the "default mode" would be that updating is explicit rather than automatic.

The "10-15" year old comment can be taken in the context of language specifications for example. C++11 is a totally fine language standard, and since backward compatibility is the only reason for C++ to exist at this point there is no intrinsic benefit in using a later version.

> "I'm suggesting the "default mode" would be that updating is explicit rather than automatic"

This, I agree with. Though for modern codebases, leveraging tools like Dependabot is very helpful. Deliberate upgrades, with automation to make it practical.

OOC, what is the benefit of having a "library" that requires such manual labor to maintain and upgrade?

You'd miss out on CVEs because you don't use the common dependency paradigm.

You'd also miss out on bug fixes if you are not detecting the bug itself.

Help me understand because I'm with you on less dependencies but this does feel a bit extreme.

Why would small functions like "difference", "groupBy", "flatten", etc. have CVEs and require bug fixes? Implementing those correctly is a one and done thing

You'd be surprised: https://positive.security/blog/lodash-ramda-underscore-vulne...

Looks like these are mostly based on "reserved" attributes (with double underscores that have no special meaning in the language, just make unintentional collisions less likely), a modern solution utilizing JS Symbol type (where needed) would have no such issues

shadcn distribution model for utils is a good idea. i wanted something for react hooks as well and was surprised that didn’t seem to exist either.

Why not copy & paste the code you need into a vendor/ subdir?

If the vendored code needs to be updated because of a change in your build tools or whatever then you’ll likely be making similar changes to other parts of your project.

This is the approach I'm sometimes using, but it would be nice to have tooling around that :)

Reply on news.ycombinator.com