We shouldn't have needed lockfiles

Site UX and Readability

• Many found the page nearly unreadable due to: bright yellow background, intrusive “presence” animation with moving avatars, and gimmicky “dark mode.”
• Multiple workarounds suggested: reader mode, disabling JS, ad/script blockers, DOM hacks (#presence removal, CSS display: none), or custom extensions.
• Some also raised mild privacy concerns about exposing viewer locations to all visitors.

What Lockfiles Are For

• Several comments stress: package specs express intent (ranges or desired versions); lockfiles record the actual resolved graph so builds are deterministic and controllable over time.
• Lockfiles let you decide when to re-run resolution (e.g., via npm ci, bundle install, cargo / pip-tools, automated “update & test” pipelines).
• Without lockfiles, rebuilding or reinstalling can silently change many transitive dependencies, causing “it broke with zero code changes” failures.

Maven, Java, and “No-Lockfile” Approaches

• The article cites Maven as proof lockfiles aren’t needed. Many strongly disagree:
  • Maven’s “nearest definition wins” (or Gradle’s “highest version wins”) can silently pick surprising versions of transitive deps.
  • Real-world stories: runtime NoSuchMethodError, JUnit/Spring conflicts, whack‑a‑mole overrides, and reliance on plugins like Enforcer.
  • Maven’s <dependencyManagement> and manual overrides effectively act as a smeared-out lockfile with worse ergonomics and no central single source of truth.
• Others report years of smooth Maven use and see Node’s culture/ecosystem as the bigger problem, not lockfiles per se.

Version Ranges, SemVer, and Security

• Pro‑range arguments:
  • Allow resolving conflicts between libraries that would otherwise pin slightly different versions.
  • Enable consumers to pick up security/bugfix releases in transitive deps without waiting for every upstream to republish.
  • SemVer is a social contract, imperfect but “good enough” in many ecosystems; misuse tends to be punished socially.
• Skeptical view:
  • Future-compatible ranges are guesses; SemVer is only a hint.
  • Some ecosystems (Node) have seen severe breakage from careless minor/patch updates.
• Several note: even with ranges, security and supply-chain concerns motivate lockfiles or equivalent hash-based mechanisms (Go’s go.sum, distro specs, vendoring).

Ecosystem Differences and Alternatives

• Python: shared environments make conflicts from pinned versions especially painful; tools often enforce strict, overlapping ranges plus lockfiles only at the application layer.
• Go: Minimal Version Selection and go.sum offer deterministic selection without a traditional lockfile, but still rely on checksums and have their own edge cases.
• Scala and others combine strict versions, compatibility schemes, and conflict checks to avoid Maven-style “YOLO” resolution.
• Some argue full vendoring is the only truly future‑proof approach; others see it as too heavy compared to lockfiles.