I have worked with Maven and dependency management is a pain. Not much nicer than vendoting dependencies like you do for C. When I first was introduced to lock files that was amazing. It solved so many problems I had with vendored dependencies, CPAN and Maven.

Just because thousands of programmers manage to suffer through your bad system every day does not make it good.

Now you're moving the goalposts; I think lockfiles that are checked-in to version control are superior to Maven's "Let's YOLO it if your transitive dependencies conflict." Version ranges are more expressive than single-versions, and when you add lockfiles you get deterministic builds.

I don't understand how Maven's YOLO is different from NPM's range.

If you force a transitive dependency in Maven, then yes, some other library may get incompatible with it. But in NPM when people declare dependency as, say, ~1.2.3 the also don't know if they will be compatible with a future 1.2.4 version. They just _assume_ the next patch release won't break anything. Yes npm will try to find a version that satisfies all declarations, but library devs couldn't know the new version would be compatible because it wasn't published at that time.

And my point is that it's _exactly_ the same probability that the next patch version is incompatible in both Maven and NPM. That's why NPM users are not afraid to depend on ~x.x or even ^x.x, they basically YOLOing.

From my experience, this is a self-policing issue in the npm ecosystem. When major packages break semver, the maintainers take a ton of heat. When minor packages do it, they quickly fall out of the ecosystem entirely. It's not "YOLO"ing, but rather following the ecosystem conventions.

But anyway.. isn't that exactly the purpose of lock files? If you don't trust the semver range, it shouldn't matter because every `npm ci` results in the same package versions.

Yeah, npm people expect that semantic versioning will be abided by. Obviously, it will not work if a minor version bump introduces a breaking change. Obviously this is better than pinning the same one dependency in literally every package - imagine the churn and the amount of life lost to bumping dependencies in any given ecosystem if every package had to pin a specific version of a dependency.

Ultimately, these are imperfect solutions to practical problems, and I know that I much prefer the semantic versioning and lockfile approach to whatever the java people are into.

> I don't understand how Maven's YOLO is different from NPM's range.

The person who wrote the range selected a range that they deem likely to work.

I don't use NPM, but in Python it definitely happens that you see e.g.:

  foo >= 0.3.4, <= 0.5.6

Which can save a lot of headaches early on for packages that use ZeroVer[1]

1: https://0ver.org/

Maven builds are deterministic (so long as you don't have SNAPSHOT dependencies). The version resolution is insane but deterministic. You'll only break that determinism if you change the dependencies.

That's precisely because maven doesn't support version ranges. Maven artifacts are also immutable.

Maven also supports manual override when the insane resolution strategy fails that's the "dependencymanagement" section.

I typically just add an <exclusion> for one of my top level dependency, so Maven picks from some other.

Lockfile builds are also deterministic. You only break that determinism if you change the lockfile.

You can use version range with a maven plugin

https://maven.apache.org/enforcer/enforcer-rules/versionRang...