[lakpan]

> Someone else who checks out your code will get different results.

> I was hoping for something like Go’s minimum version dependency resolution.

Uh and that’s different how? The default semver range is “minimum dependency version” with an upper bound in the current major.

[skybrian]

The upper bound resolves to a different version after a new minor version is published. That’s nondeterministic. Someone else checking out your project will get different results, unless you use a lock file.

[lakpan]

See, you don’t know how npm works. Npm does not care about the lockfile of dependencies. “Someone checking out my project” always gets the latest version of each dependency within the semver range, until their lockfile locks a version into place.

[skybrian]

I meant someone checking out the exact same Github repo (for an application), not someone depending on a library I released. If you have a lock file, it works in that case, I believe?

But actually I use Deno, and I'm honestly not sure how that works either.

As for library dependencies, I know how it works in Go, which is how it should work. When you add a dependency, and it has its own dependencies that you don't use directly, you get the same version that they tested with, which is the lowest one they specified. It only gets overridden if something else requires a higher version.

This means that when a new version gets released somewhere, nothing happens until people notice it, bump a version, and hopefully test it. No library version changes unless there's a commit.

Taking the latest minor version means that it hasn't been tested by anyone downstream. (How could they, when it didn't exist before?)

New library versions should be tested by direct dependencies before they get used by indirect dependencies.