Rajesh Menon

My entry point is the version range, because almost every install surprise starts there. A caret range permits any version below the next major, a tilde permits patches and minors within a major, and an exact version permits nothing else. They look similar and behave very differently, and a range written loosely in a library's manifest becomes somebody else's broken afternoon. Peer dependencies are the part people read least and need most. Declaring one says the package does not bundle a copy and expects the host to supply it, which avoids two incompatible copies existing at once. Declaring it wrongly, either too wide or too narrow, produces a conflict that surfaces somewhere else entirely. Lockfiles record the exact resolved tree along with integrity hashes, and they are what makes an install reproducible. Commit them for applications. The decision for libraries works differently: pinning a dependency inside a library forces that version onto everyone who installs it, so the range belongs in the manifest and the lockfile stays out of the published package. The dependency tree is larger than the manifest suggests. Most of what gets installed is transitive, which means reviewing direct dependencies tells you very little about what runs. A tool that shows the tree with versions is worth more here than one that counts packages. I finish on supply chain basics, because the registry is a public upload channel. Pinning to an integrity hash, reviewing new maintainers on a dependency you did not choose deliberately, and checking install scripts are the three checks that catch most of it.