It's the exact same for me. The spiders are by far the most visceral fear response, especially if a gruesomely detailed photo pops up on my phone.
Smaller spiders scared me when I was younger, but I have overcome that phobia significantly. Large, hairy, distinctly arthropodic spiders, though...? Yuck.
Question for both you and GPP; is this fear limited to real life depictions, or basically anything? E.g, if you ever played Skyrim or a game with spider-like enemies does it have the same effect as a real spider?
Answers I've seen to this question tend to vary wildly.
Spider-fear has never been triggered by fictional spiders for me. Very few works ever bother getting the face and body right though. 8 legs alone are not scary for me, the fangs and eyes and color patterns and the sneaky movement and webs are scary.
I'm not terribly afraid of real spiders though. Hairy crawling spiders like wolf spiders and tarantulas don't really bother me at all. It's the ones with the big web-spinning butts that dangle and drop down from above that make me go straight into fight-or-flight.
I did play Skyrim, and I was fine with it. Something about video games takes the fear out of it. I mean, they're definitely a little bit more unsettling than other video game creatures, but not by much, so I don't get a fear response. I'd react more to a "jump scare" in a game than a 3D spider.
I'm also really afraid of snakes, but spiders are okay.
Movies with snakes are quite painful to watch too, and I'm very uncomfortable with snakes in video games, but at least I have some control (compared to TV) so it's a significantly better experience
I get that it's a joke, but I feel the need to defend this project anyway.
The problem with NPM isn't any one young package. The problem with the NPM is that any time you run 'npm install', you download potentially thousands of packages, and you get the most recent patch release from all of them. Installing one 1-day-old NPM package to forever avoid day 1 releases of thousands of packages seems like a worthwhile trade.
Still, I would maybe choose the tried and true PNPM instead, which supports this too.
> The problem with NPM isn't any one young package. The problem with the NPM is that any time you run 'npm install', you download potentially thousands of packages, and you get the most recent patch release from all of them.
Isn't this simply wrong?
Last I checked, lock files work. They didn't for a long time, until a couple of years ago, as far as I know.
If you delete your lock file or explicitly run a package upgrade, sure, you get the latest versions compatible with your semver ranges.
> Installing one 1-day-old NPM package to forever avoid day 1 releases of thousands of packages seems like a worthwhile trade.
If you want to be extra sure, you can simply not use semver ranges in your package.json, or only for select packages.
Lockfiles work if you combine them with version pinning (exact version, no semver), or always run `npm install ci` unless you’re intentionally attempting to update your packages.
I’ve always preferred exact versions because I’d rather updates be opt-in rather than an opt-out footgun. Otherwise any new dev to the project might accidentally pull some new version of a package that satisfies the semver requirement but modifies the lockfile, then they’ll check it into the code, and it’s another thing to fix at review time… there’s just a lot less friction if you use exact versions. It makes hermetic/reproducible builds and static dependency analysis easier, too.
Of course you need some update hygiene, preferably via an automated bot that opens PRs and runs tests. Renovate works well.
(btw, this same issue occurs with Docker base images; it’s better to base images on the sha256sum of the target image rather than a floating tag. Renovate can update those too.)
You are right that 'npm install' can upgrade versions even when a lock file is present, but AFAIK this should only happen it the lock file is not compatible with the package.json. I haven't seen it in a long time, and AFAIK it can't happen without you changing the package.json.
But yes, it's a reason to pin dependencies and use npm ci / yarn immutable etc.
Updates of transitive dependencies are afaik not automatically installed when there is a working lock file: this is the thing that changed some versions ago I think (I mixed up Node and npm versions in my initial comment).
So yes, to be sure that you never install anything else, it's best to use 'npm ci' or 'yarn install --immutable', which will fail if the lock file is broken or not present.
But 'npm install' does not install the latest patch release compatible with your package.json with precedence over the lockfile.
What it does do is upgrade if you edit the version range by hand to be incompatible with the lock file, e.g. increase major version of a package.
But if you have, say, Typescript ^5 in your package.json, but 5.4 in your lock file, 'npm install' won't upgrade it.
> If the package has a package-lock, or an npm shrinkwrap file, or a yarn lock file, the installation of dependencies will be driven by that, respecting the following order of precedence:
> npm-shrinkwrap.json
> package-lock.json
> yarn.lock
'npm ci' and friends are safer as they will always fail when they can't install from lock file without any conflicts or changes, that's correct.
Don't know how other package managers behave in this regard, except for yarn and pnpm.
reply