Dependency Resolution & Versioning

Forcing one version everywhere can silently break whichever library wasn't actually tested against that version, since the build tool doesn't check compatibility for you. It's risky when the two required versions are truly incompatible (a real major breaking change), not just a routine version mismatch.

Strict install modes wipe out existing node_modules and reinstall purely from the lockfile, and they refuse to run at all if the lockfile doesn't exactly match the manifest -- catching cases where someone forgot to update the lockfile after changing dependencies, instead of silently patching the mismatch like a normal install would.

Versions starting with 0 (like 0.4.2) are 'anything can change, anytime' under SemVer - even a MINOR bump can break things. Maintainers use this to keep freedom to redesign the API while people are still testing it out, even if lots of people already use it.

You can swap heavy libraries for lighter ones, remove dependencies you don't actually use, let the package manager dedupe overlapping versions, or pin versions so the graph stops silently growing - but each of these costs either engineering time, some feature, or some flexibility.

Tree-shaking is a bundler feature that deletes code you imported but never actually use, so your final downloaded JavaScript file is smaller — but it only works if the library is written in a way the bundler can statically analyze.

The build tool likely picked the wrong version of a shared library that two dependencies both need. You'd inspect the dependency tree for duplicate versions of the same library, find which two consumers disagree, and pin the graph to a version that satisfies both.

You need more than good intentions: a clear written definition of what's 'public API,' automated checks that catch accidental breaking changes before merge, a required human sign-off for anything flagged as breaking, and a changelog that's actually generated from real diffs. Skip any of these and the version number slowly stops meaning what it claims.

A SAT-style resolver treats version picking as a constraint problem across the whole graph and searches for a combination that satisfies everyone's stated requirements, backtracking if needed - and it can honestly report 'no solution exists' instead of silently picking something broken.

Committing node_modules means the exact installed dependency files travel with the repo, so a fresh checkout runs immediately without needing to reinstall anything — but it makes the repo huge and hides security problems from normal tooling.

You can trick the JVM into treating the two copies as different libraries entirely — either by loading each plugin's classes with its own separate loader so they don't share names, or by physically renaming one copy's internal package names so they no longer look like the same library. Both add real complexity and memory/build overhead in exchange for avoiding a forced single-version pick.

Some packages install a different native binary sub-package per operating system/CPU combination, listed as optional dependencies; if the lockfile format only records what was resolved on the platform that generated it, other platforms' entries can be missing or the wrong ones can get reused during install.

Provenance is proof of exactly how and where a piece of software was built — which source commit, which build system, run by whom — cryptographically signed so it can't be faked. It catches attacks where the published artifact doesn't actually match its claimed source, which a simple inventory list can't detect. Requiring it everywhere at once can be impractical because most packages don't provide it yet.

Decisions like whether every service resolves its own dependency versions independently or shares one company-wide set, how strict the rules are for adding a new dependency, and whether you track the whole graph centrally all change how bad the mess gets - and each choice trades flexibility for consistency, or speed for safety.

Don't pick one extreme for everything. Let low-risk dependencies float and update automatically through reviewed pull requests; pin or tightly restrict the few dependencies where a break would be very costly; and measure how long it takes services to actually adopt a security patch so you can catch the laggards.