I agree that many packages in the JS ecosystem don't respect semantic versioning, which is why I pin my dependencies to an exact version. For updates, I rely on

I agree that many packages in the JS ecosystem don't respect semantic versioning, which is why I pin my dependencies to an exact version. For updates, I rely on automated bots submitting PRs that update a single package at a time and run my test suites. But even if they did respect semver, I'd still use exact versions, because I want full control over when I update my dependencies, and I don't want lockfile updates leaking into unrelated PRs just because a developer ran `yarn install`. Yes, you can use `yarn install --immutable` (and you should in CI/prod), but this will fail if the lockfile changes, which it would if the semver resolved to an updated version. I just want to `yarn install` without changing the lockfile. If you pin to an exact version, and use a lockfile, then you won't ever pull in any updates on `yarn install`, and installing your package in three years will result in downloading the exact same code as it does today. Just make sure you use nvm to pin Node, and corepack to pin your package manager, and you have a fully reproducible build chain as long as the dependencies are not unpublished from npm (which they can't be, after 72 hours of publishing). The only time it makes sense to use a semver range is in the `peerDependencies` of a published library. Even the `dependencies` of a library should use an exact range. Why? Because firstly, if I'm following best practices, I should be bundling my library before publishing it as a package. And secondly, if that bundle depends on another package, that's okay because npm dependency model allows having multiple copies/versions of the same package. But if it's something like Emotion depending on React, where I only want one copy of the library at runtime, then I should use a peer dependency, and here it does make sense to refer to it with a semver range.