> The specific misfeature is that when you use NPM to install a package, including a command-line tool, NPM selects the dependency versions according to the req

> The specific misfeature is that when you use NPM to install a package, including a command-line tool, NPM selects the dependency versions according to the requirements listed in package.json I thought in 2021 its well known that not using locked dependencies for npm is a no-go? Just people accidentally braking dependencies happens so often that in my experience not using a lock file is not an option. > a package declares the minimum required version of each dependency, and that’s what the build uses if that is how it works it IMHO sounds like a way worse choice for security. Personally I prefer what cargo (rust) does, if there is no lock file, pick the newest compatible version and create a lock file. If there is a lock file use the version of the lockfile (if possible, i.e. if the semver requirements in the project file are not incompatible with the current lock file). Then it's not a question of weather you use some command to create some freez/lock file or similar, but just weather you commit it. It also means that during local development your version will not magically bump (which would be horrible). Similar you can tell cargo to bump dependencies in the lock file to the newest semver compatible version, or increase the minimal version number in the Cargo.toml file. Similar you can use options to _only_ use dependencies in the lock file failing if it's not compatible with the current project definition. Sure cargo still has a lot of ways it can improve in, but I still prefer it over more or less all alternatives I ever tried (I haven't tried all of them).