You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore.

It's the sort of terrible practice that someone might be frustrated into taking after a nasty merge conflict, and signals a willingness to cut corners.

▲ DanielHB 3 hours ago | parent | next [-]

My lockfile was not gitignored, I had made significant changes to package.json so I was expecting diffs in the lockfile.

I just don't usually read lockfile diffs and claude inadvertently updated a few dozen packages to new minor versions without me noticing. In fact I only realized the problem after I looked at the lockfile diff.

▲ esperent 3 hours ago | parent | prev [-]

> You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore.

What would be the point of that? Do you just go around hunting for bugs in random repos?

▲ eterm 2 hours ago | parent | next [-]

Sure, in the spirit of open source, why not? It's a hobby, and it scratches an itch. I very much enjoy deconstructing things more than putting them together.

We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month.

Ignoring the eco-terror aspect of that for now, it means there's an awful lot of code out there which is finding itself under constant attack by a fleet of hostile AI.

I don't personally believe that the solution to that is "more AI", which firstly just overwhelms maintainers and secondly surrenders our human agency to a giant machine, with a hope that the "good" side can out-spend the bad.

Nor do I think the solution is to abandon the open internet and retreat behind corporate walls into curated spaces, "benevolently" protected by giant companies.

Which means holding on to the open internet requires a human approach, and any signal to help amplify the work there is a benefit.

▲ order-matters 2 hours ago | parent [-]

>We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month

whoa what? which one is that?

▲ eterm an hour ago | parent | next [-]

As another commenter said, it's "is-even":

https://github.com/i-voted-for-trump/is-even

From that page:

> I created this in 2014, when I was learning how to program.

I've nothing against Jon Schlinkert, it's not his fault the way we build software is more than messed up, where our build systems are so brittle that, "Throw out the universe and rebuild it from scratch" became not just acceptable, but the main way to get build systems to work reliably.

▲ hnuncommon 2 hours ago | parent | prev [-]

Check is-even and is-odd npm packages. https://www.npmjs.com/package/is-even

▲ vel0city an hour ago | parent [-]

That's still quite a ways away from 500M+ downloads a month, more like ~4M downloads a month.

Still a huge number of downloads, don't get me wrong!

▲ eterm an hour ago | parent [-]

You're right, I was reading the stats for "is-number" and mixing them up for "is-even":

https://www.npmjs.com/package/is-number

170M downloads / week.

Same author, similar vintage. Arguably a necessary package, but that just further indicates how messed up javascript was.

▲ vel0city an hour ago | parent [-]

So nuts.

> Arguably a necessary package

Arguably a somewhat important part of a standard library!

	▲	eterm 28 minutes ago \| parent [-]
		A large part of the problems of Javascript are corollaries of lacking of a good standard library, and the relatively long time it took and is still taking to fix that. It wasn't really until ES2015 that a better standard library really started to take shape, and, thanks to IE11, it was a very long time before that didn't need poly-filling. In a sane world, you'd just parse whatever you're after and then check for NaN or null. You can't do that. Pop open your favourite javascript runtime and type: `Number.parseInt("123Garbage")`

▲ gwbas1c 2 hours ago | parent | prev [-]

It's also a good practice when taking a new job, especially if someone is a contractor and changes gigs every few months or years.

I've found that, when I start a job, I have to rely on smells like this to know what kind of mess (or if there is a mess) I need to clean up.