I would rather work with a company that updates continuously, while also building security into multiple layers so that weaknesses in one layer can be mitigated by others.

For example, at one company I worked for, they created an ACL model for applications that essentially enforced rules like: “Application X in namespace A can communicate with me.” This ACL coordinated multiple technologies working together, including Kubernetes NetworkPolicies, Linkerd manifests with mTLS, and Entra ID application permissions. As a user, it was dead simple to use and abstracted away a lot of things i do not know that well.

The important part is not the specific implementation, but the mindset behind it.

An upgrade can both fix existing issues and introduce new ones. However, avoiding upgrades can create just as many problems — if not more — over time.

At the same time, I would argue that using software backed by a large community is even more important today, since bugs and vulnerabilities are more likely to receive attention, scrutiny, and timely fixes.

> I would rather work with a company that updates continuously, while also building security into multiple layers so that weaknesses in one layer can be mitigated by others.

Sorry, if you are updating continuously, that there is at least one layer that you failed to build any security into.

You forgot case #4: Worked at a startup where the frontend team thought it was a good idea to use lock files during development, but to do a "fresh" install of all dependecies during the deployment step.

And yes, they still thought they were doing the right thing.

To be fair npm makes (made?) it weirdly hard to use lock files so a lot of people did that by mistake. And when you do use lock, it reinstalls every time so a retagged package can just silently update.

FYI a retagged package would result in a different SHA512 integrity sum and fail the installation process. It won't "just silently update".

Anyway, the point of parent and me wasn't that it was considered to be a "mistake", but people thinking they "are doing the right thing".

I can’t comment on the behavior of ancient npm versions, but with modern npm I would not even know how to skip using a lockfile.

As for the parent comment about not using the lockfile for the production build, that’s just incredibly incompetent.

Maybe they should hire someone who knows what they are doing. Contrary to the popular beliefs of backend engineers online, you also need some competency to do frontend properly.

In this case what’s needed is „npm ci“ instead of „npm install“ or better „pnpm install —frozen-lockfile“.

Pnpm will also do that automatically if the CI environment variable is set.

[delayed]

Lock files were begrudgingly introduced after people who aren’t playing around with move fast and break things cried foul about dependencies being updated unexpectedly. The “semantic versioning” dogma and the illusion of safety that it brings was the original motivation. At NPM’s creation time, mature dep management ecosystems did not have floating versions, they were always pinned.

When you are talking about checking your dependencies in the source tree, you are effectively pinning exact versions, and not using floating/tilde versioning syntax.

That breaks if the library uses build scripts, like for setting up native binaries, or native modules linked against the specific Node version.

If you want a vendored deps model you can look at Yarn Plug and Play which does this via .zip files.

However, I would just stick with regular pnpm and installs.

> That breaks if the library uses build scripts

Uh… no.

> setting up native binaries, or native modules linked against the specific Node version

So the majority of projects—those that don't use binary NodeJS modules—don't have a reason for sidestepping the primary VCS and going along with npm's shoddily designed overlay version control approach?

> However, I would just stick with regular pnpm and installs.

You're not answering the question. npm isn't bedrock, and pnpm certainly isn't. If you're going to introduce (mandate) the use of a tool in the workflow, you should be able to justify it by explaining your rationale for introducing it (and making everyone deal with the associated costs). You should at minimum be able to provide a lucid explanation of the tradeoffs. For good measure, you should be able to disprove the "NPM Null Hypothesis"; you should be able to state a straightforward answer to the question, "What problem is this supposed to be solving?"

doesn't `npm ci` prevent that? it fails if something doesn't match the lockfile, and wipes node_modules before running

this is on some ancient node 16 build i was trying to clean up ci for, so not very recent npm

npm ci does indeed prevent that. The issue isn't really with npm in specific. Rather, it's with build tools like Microsoft's Oryx, which get pushed in GitHub Actions if you're using Azure App Service. That one by default uses `npm install` on older versions (it's been changed nowadays, but Azure's generated action files have a bad habit of generating with older versions of the actions they're using), even though it's specifically meant for CI usage.

In general, use of npm ci is usually sparsely documented - most node projects you can find just recommend using npm install during the setup, suggesting a failure in promoting it's availability (I only know of it because I got frustrated that the lockfile kept clogging up git commits whenever I added dependencies with what looked like auto-generated build-time junk).

This was true in very old npm - generating the lock file was a separate command - npm shrinkwrap. And many people didn't know they should check in the shrinkwraps. But I think the default flipped before 2020 so that it now always creates package-lock.json files (unless an npm-shrinkwrap.json is present and then it uses /updates that)

Another example of this is Python and its awful externally-managed-environment handling, for which the procedure for anyone who doesn't use Python every day boils down to:

1. Get instructions from somewhere, a web page, HOWTO, whatever, telling you to "pip install thing".

2. "× This environment is externally managed"

3. Spend awhile Googling how to get past this and just make the damn thing work while swearing.

This is from observing users in practice. Google "This environment is externally managed" and you'll get nothing but hits on (a) people asking what this means and how to make it go away and (b) various unsafe methods to make it so.

This is one of those bizarre "how did you even get that idea" mistakes that ironically replacing developers with AI slop farmers might actually improve on. If you ask Claude to set up a project with NPM and CI, it's not going to do weird shit like that.

I asked Claude to set up a new NPM project and it configured the install task as “npm ci || npm install”, which is stupid. That was on Opus4.7 xhigh. When I pointed out that doing so defeats the purpose, it said “oh yeah of course.”

Turns out there is no equivalent to “npm ci” that doesn’t clear node_modules first, and you can’t call npm install to simulate NPM ci behavior (sans clean).

How else are you sure your team does not conflict with itself?

/s

> Everyone seems to think they are doing the right thing

I like to think people would agree more on the appropriate method if they saw the risk as large enough.

If you could convince everyone that a nuclear bomb would get dropped on their heads (or a comparably devastating event) if a vulnerability gets in, I highly doubt a company like #2 would still believe they're doing things optimally, for example.

Really? You think the alternate mode where you're running 5-year-old versions of stuff with tons of known security flaws is better?

What part of "We reviewed all relevant CVEs as they came out to make a call on if they apply to us or not and how we mitigate or address them" gave you that impression?

My experience with how such a strategy typically plays out in reality.

>running 5-year-old versions of stuff with tons of known security flaws

No one in this thread proposed that, or anything that could be reasonably assumed to have meant that.

> if they saw the risk as large enough.

If you expose people to the true risks instead of allowing them to be ignorant, the conclusion that they might come to is that they shouldn’t develop software at all.

The assumption was obviously that they have a compelling need to develop the software. For the sake of illustration: you imagine exposing them to whatever the highest level of risk is that still makes them wiling to develop software.

Do you ride an R1?

I used to ride a 600R ... yes- that's where my handle comes from ;)

> It's impossible to convince the "frequent upgrader" that maybe that's a risk in terms of introducing new issues

I would count myself as a "frequent upgrader" - I admin a bunch of Ubuntu machines and typically set them to auto-update each night. However, I am aware of the risks of introducing new issues, but that's offset by the risks of not upgrading when new bugs are found and patched. There's also the issue of organisations that fall far behind on versions of software which then creates an even bigger problem, though this is more common with Windows/proprietary software as you have less control over that. At least with Linux, you can generally find ways to install e.g. old versions of Java that may be required for specific tools.

There's no simple one-size-fits-all and it depends on the organisation's pool of skills as to whether it's better to proactively upgrade or to reluctantly upgrade at a slower pace. In my experience, the bugs introduced by new versions of software are easier to fix/workaround than the various issues of old software versions.

> It's impossible to convince the "frequent upgrader" that maybe that's a risk in terms of introducing new issues.

Well, you critisize people who run the latest software here. Two counter-arguments:

1) If you don't upgrade frequently, you end up with super stable debian stuck on ... ancient software. This in turn means that many more recent software, won't work, unless you recompile a lot. I had this issue with mesa for instance, then needing a more recent LLVM, spirv-components and so forth. No chance to have that easily on debian, unless you control what you compile. On my local system here I run gtk2, gtk3 and gtk4 just fine. Good luck having that with debian for recent version; even debian sid is slow compared to, say, gentoo or arch(linux) or void(linux) here.

2) Even debian systems would be vulnerable to copy.fail. So that strategy is also not automatically better.

Personally I am among the frequent update folks. I use ruby scripts to automatically update to the latest, in hope that the people who write code are not incompetent. There is no guarantee that newer software is automatically always better; it is a trade-off. I don't have the time and resource for infinite security audits. I need to get things done and this approach, different to the "everything is scary" crowd, works super-well for me. I use a versioned AppDir approach on linux though, so I don't run into many issues of "can not upgrade because of same .so name issue", so I can conveniently switch to other versions as-is, including the kernel. (Excluding ABI differences and glibc, but for about 98% of the programs this works very well. I am also not alone with the get-everything-working approach, see xserver or gtk2-ng: https://github.com/X11Libre/xserver https://git.devuan.org/Daemonratte/gtk2-ng - granted, for the linux kernel this does not work that well ... I think we need better strategies for the linux kernel, things such as copy.fail should not be possible. I have no good solution here, AI will find many more exploits. No clue how we can prevent this or mitigate this more easily. I was surprised when the local instructor showed us how easy it is to use python for gaining superuser access as-is.)

Debian had backports since forever. You could totally upgrade the kernel and MESA since month 1.

Not forever, backports were introduced with Sarge IIRC. And typically versions only appears in backports that are also in testing/unstable, e.g. Linux 6.19 is currently in trixie-backports but the non-LTS kernels between 6.12 and 6.18 were not available there, nor is the current 7.0 (yet).

Pulling the very latest of everything is IMO risky. What I will acknowledge is that not knowing what known issues are in your stack vs. just pulling the latest all the time is less clear. But running more stable older versions of software while tracking new vulnerabilities seems like it mitigates both the risk of new changes introducing new issues and the risk of a new vulnerability not getting addressed. This worked well for company #1 where we delivered some pretty critical products and the bar was very high for reliability and security.

A long time ago I heard that Google reviews every single line of third party code they use, not sure if it's true or if they still do it.

Honestly the de facto standard is to blame: at my dev job, we vacuum up all the packages we need and get the software deployed to production ASAP, then later go over the SBOM and make sure nothing looks sketchy. I'd imagine this is the default most places; an intensive approval process would slow down CI/CD too much.

What's the conservative best practice for a solo founder (a one person company; assume the person spends ~20 hours per week on software development/maintenance and the rest of the time on other stuff)?

It's interesting how standards have changed. 25 years ago people screamed about ActiveX despite Microsoft's various attempts to lock it down. Today people use something that pulls a package from a Github repo that was abandoned eight years ago that pulls a package from an FTP server in Denmark that pulls a package from a Raspberry Pi in someone's basement in New Mexico and it's all good practice.