The lockfile only applies when you run `npm install` in the project directory, other projects using your package will have their own lockfile and resolve your dependencies using only your package.json.

The irony is that it even has something like lockfiles as well: The <dependencyManagement> section:

> Dependency management - this allows project authors to directly specify the versions of artifacts to be used when they are encountered in transitive dependencies or in dependencies where no version has been specified.

It's just less convenient because you have to manage it yourself.

The author of the article asked the same question in his personal blog in Telegram a year and a half ago [1], and received in response exactly the same example with maven. Probably, to build a personal brand and increase visibility, he needs to ask the same thing many times in different places.

1. https://t.me/nikitonsky_pub/597

The java ecosystem never went through the level of pain node ecosystem has. For a while it was simply insanity in node. I've worked heavily in both, and the developer experience in java was always way better.

Seems like there's room then in the Maven ecosystem that does what maven-enforcer-plugin does, but which just looks at a lockfile to make its decisions.

To add: if you would like to avoid depending on Maven's dependency mediation behaviour, then a useful tool is Maven Enforcer's dependencyConvergence rule.

https://maven.apache.org/enforcer/enforcer-rules/index.html

When I used to lead a Maven project I'd take dependency-upgrade tickets that would just be me bumping up a package version then whack-a-moling overrides and editing callsites to make dependency resolution not pull up conflicting packages until it worked. Probably lost a few days a quarter that way. I even remember the playlists I used to listen to when I was doing that work (:

Lockfiles are great.

If you use two dependencies, and one requires Foo 1.2.3 and the other Foo 1.2.4 then 99% of the time including either version of Foo will work fine. (I was a Java developer and used Maven for about 10 years.)

For those times where that's not the case, you can look at the dependency tree to see which is included and why. You can then add a <dependency> override in your pom.xml file specifying the one you want.

It's not an "insane" algorithm. It gives you predictability. If you write something in your pom.xml that overrides whatever dependency your dependency requires, because you can update your pom.xml if you need to.

And because pom.xml is hand-written there are very few merge conflicts (as much as you'd normally find in source code), vs. a lock file where huge chunks change each time you change a dependency, and when it comes to a merge conflict you just have to delete the lot and redo it and hope nothing important has been changed.

npm got around to `@{author}/{package}` and `@{org}/{package}` beyond just global `{package}`, albeit midstream, rather than very early on. The jargon is "scoped packages". I've seen more adoption recently, also with scopes for particular projects, like https://www.npmjs.com/package/@babel/core

I have YEARS of zero problems with maven dependencias. And yet i cant leave up a node project for more than a month without immediately encountering transitive dependency breakage that take days to resolve.

Maven is dependency heaven.

Yeah, this felt like a gap in the article. You'd have to wait for every package to update from the bottom up before you could update you top levels to remove a risk (or you could patch in place, or override)

But what if all the packages had automatic ci/cd, and libinsecure 0.2.1 is published, libuseful automatically tests a new version of itself that uses 0.2.1, and if it succeeds it publishes a new version. And consumers of libuseful do the same, and so on.

I think you missed the point of the article. Consider Application A, that depends on Library L1. Library L1 in turn depends on Library L2:

A -> L1 -> L2

They are saying that A should not need a lockfile because it should specify a single version of L1 in its dependencies (i.e. using an == version check in Python), which in turn should specify a single version of L2 (again with an == version check).

Obviously if everybody did this, then we wouldn't need lockfiles (which is what TFA says). The main downsides (which many comments here point out) are:

1. Transitive dependency conflicts would abound

2. Security updates are no longer in the hands of the app developers (in my above example, the developer of A1 is dependent on the developer of L1 whenever a security bug happens in L2).

3. When you update a direct dependency, your transitive dependencies may all change, making what you that was a small change into a big change.

(FWIW, I put these in order of importance to me; I find #3 to be a nothingburger, since I've hardly ever updated a direct dependency without it increasing the minimum dependency of at least one of its dependencies).

It also covers a whole 1/4 of the screen on mobile...

The point isn't, "There are zero problems with maven. It solves all problems perfectly."

The point is, "You don't need lockfiles."

And that much is true.

(Miss you on twitter btw. Come back!)

> I even remember the playlists I used to listen to when I was doing that work (:

Im a big fan of anything Aphex Twin for these type of sessions.

Yes, but if later Dep1 and Dep2 stop depending on Foo you will never know about it.

Depending on the dependency, you can also use shadow versions right? Essentially including both versions, and providing each dependency with it's own desired version. I believe it's done with the maven shade plug-in

Never used it myself though, just read about it but never had an actual usecase

The issue is what happens when libX@latest is updated and uses libd@2.0 but your other dependency libA@latest uses libd@1.3.1? In maven, crazy things happen. Sometimes it’s fine but if you have any kind of security, the version mismatch has different signatures and blows up. Ask any spring developer what happens when they have more than 1 slf4j in their classpath.

That's a problem with node's culture, not with lockfiles. I've never experienced the level of bitrot Node suffers from in Rust, Ruby, Go, or PHP, which do have lockfiles.

> encountering transitive dependency breakage

Are you talking about a dependency not declared in your lock file? Or are you talking about a dependency in your lock file being unavailable, ex. no longer in npm, in a months time?

Go has a deterministic package manager and handles security bugs by letting library authors retract versions [1]. The 'go get' command will print a warning if you try to retrieve a retracted version. Then you can bump the version for that module at top level.

You also have the option of ignoring it if you want to build the old version for some reason, such as testing the broken version.

[1] https://go.dev/ref/mod#go-mod-file-retract

> compile and run programs with incompatible version dependencies and then they crash at some point

Just because Java does this doesn't mean every language has to. It's not strongly tied to the dependency management system used. You could have this even with a Java project using lockfiles.

> a package 5 layers deep is unmaintained and is on an ancient dependency version, other stuff needs a newer version. Now what? Manually dig through dependencies and update versions?

Alternatively, just specify the required version in the top-level project's dependency set, as suggested in the article.

Funnily enough PHP solved this perfectly with composer, but unfortunately it's not an enterprise-level programming language /s

Agreed, and the fact that there is not an easy "x" to close it is even worse.

If you want to do something cute and fun, whatever its your site. But if you actually want people to use your site make it easy to dismiss. We already have annoying ads and this is honestly worse than many ads.

Also, from the bio that I can barely see he writes about "UI Design" and... included this?

I read the article but that animation was incredibly distracting. I don't even understand what it's for - clicking it does nothing. Best guess is a representation of how many people active on page.

As someone who does like tonsky’s stuff sometimes: I immediately closed the article when I saw it. I’m less charitable than you: it’s not cute, it’s just annoying, and it should be able to be switched off. For me it goes into the same box as his “dark mode” setting but it’s worse because it can’t be disabled. Why should I, as the reader, put in effort to overcome something the author found “cute” just to read their words? It’s akin to aligning the words to the right, or vertically: I can read it but it’s so much work that I’d rather just not.

On sites like that, I typically just switch to "reader view" which the leaves only the interesting content.

The animation? For me it was the blinding yellow background

> All of the versions need to align to pass `Regex` between yourself and your dependencies.

In nominally typed languages, all types have to be nominally the same, yes, but it does not follow that semver compatible packages will not permit passing different versions of each around: https://github.com/dtolnay/semver-trick (the trick is to ensure that different versions have nominally the same type by forward dependency).

Anyways, even with this, cargo has a lock file because you want to run in CI what you ran when you developed the feature instead of getting non-deterministic executions in an automated build + verification. That's what a deterministic build is aiming for. Then next feature you develop you can ignore the lockfile, pull in the new dependencies and move on with life because you don't necessarily care for determinism there: you are willing to fix issues. Or you aren't and you use the lockfile.

> All of the versions need to align to pass `Regex` between yourself and your dependencies.

No, they don't. As the article explains, the resolution process will pick the version that is 'closest to the root' of the project.

> The second impact will be that your builds will be slow....you are working across your dependency tree to get everything aligned.

As mentioned earlier, no you're not. So there's nothing to support the claim that builds will be slower.

> You now need to work through the entire bubble up process before it becomes available to you.

No you don't, because as mentioned earlier, the version that is 'closest to root' will be picked. So you just specify the security fixed version as a direct dependency and you get it immediately.

Strongly endorse. That paper is really wonderful. It seems to me that MVS is the solution to the version selection problem, and now we just have to wait for awareness of this to fully percolate through the developer community.

With deterministic version control, library authors are supposed to document the exact version that a library was tested with. (Or the oldest version that they tested with and still works.)

People who use a library might use newer versions (via diamond dependencies or because they use latest), but it will result in a combination of dependencies that wasn't tested by the library's authors. Often that's okay because libraries try to maintain backward compatibility.

Old libraries that haven't had a new release in a while are going to specify older dependencies and you just have to deal with that. The authors aren't expected to guess which future versions will work. They don't know about security bugs or broken versions of dependencies that haven't been released yet. There are other mechanisms for communicating about that.

How do lockfiles solve this problem? You would still have dependency-upgrade tickets and whack-a-mole, no? Or do you just never upgrade anything?

What happens when one requires Foo 1.0 and the other requires Foo 2.0, and the two are incompatible on ABI level?

> You can then add a <dependency> override in your pom.xml file specifying the one you want.

Isn't that basically a crappy, hand-rolled equivalent to a lock file?

You might not have issues, but they definitely happen. Especially once you bring in heavy frameworks like Spring, which for some reason ship with a ton of dependencies, some of which are surprisingly outdated.

I had this happen with JUnit after a JDK upgrade. We needed to update to a newer major version of JUnit to match the new JDK, so we updated the test code accordingly. But then things broke. Methods were missing, imports couldn't be resolved, etc. Turned out something else in the dependency tree was still pulling in JUnit 4, and Maven's “nearest-wins” logic just silently went with the older version. No error, no warning. Just weird runtime/classpath issues. This something else turned out to be spring, for some odd reason it was an ancient version of Junit 4 as well.

And yeah, you can eventually sort it out, maybe with mvn dependency:tree and a lot of manual overrides, but it is a mess. And Maven still doesn't give you anything like a lockfile to consistently reproduce builds over time. That's fine if your whole org pins versions very strictly, but it's naive to claim it "just works" in all cases. Certainly because versions often don't get pinned that strictly and it is easy to set up things in such a way that you think you have pinned the version while that isn't the case. Really fun stuff..

The automatic ci/cd suggestion sounds appealing, but at least in the NPM ecosystem, the depth of those dependencies would mean the top-level dependencies would constantly be incrementing. On the app developer side, it would take a lot of attention to figure when it's important to update top-level dependencies and when it's not.

What if libinsecure 0.2.1 is the version that introduces the vulnerability, do you still want your application to pick up the update?

I think the better model is that your package manager let you do exactly what you want -- override libuseful's dependency on libinsecure when building your app.

Slightly off topic but we need to normalize the ability to patch external dependencies (especially transitive ones). Coming from systems like Yocto, it was mind boggling to see a company bugging the author of an open source library to release a new version to the package manager with a fix that they desperately needed.

In binary package managers this kind of workflow seems like an afterthought.

The author hints very briefly that Semantic Version is a hint, not a guarantee, to which I agree - but then I think we should be insisting on library maintainers that semantic versioning *should* be a guarantee, and in the worst case scenario, boycott libraries that claim to be semantically versioned but don't do it in reality.

It’s totally fine in Maven, no need to rebuild or repackage anything. You just override version of libinsecure in your pom.xml and it uses the version you told it to

1) "it will just compile and run programs with incompatible version dependencies and then they crash at some point"

2) "Now a package 5 layers deep is unmaintained and is on an ancient dependency version, other stuff needs a newer version. Now what? Manually dig through dependencies and update versions?"

You can't solve both of these simultaneously.

If you want a library's dependences to be updated to versions other than the original library author wanted to use (e.g. because that library is unmaintained) then you're going to get those incompatibilities and crashes.

I think it's reasonable to be able to override dependencies (e.g. if something is unmaintained) but you have to accept there are going to be surprises and be prepared to solve them, which might be a bit painful, but necessary.

I've never seen something so egregious before, it made it impossible to read without covering it with my hand.

But I realized something by attempting to read this article several times first.

If I ever want to write an article and reduce peoples ability to critically engage with the argument in it I should add a focus pulling animation that thwarts concerted focus.

It's like the blog equivalent of public speakers who ramble their audience into a coma.

It's downright awful and I'm having a hard time imagining the author proof reading their own page and thinking "yeah, that's great".

As an aside, I have an article in my blog that has GIFs in it, and they're important for the content, but I'm not a frontend developer by any stretch of the imagination so I'm really at wit's end for how to make it so that the GIFs only play on mouse hover or something else. If anybody reading has some tips, I'd love to hear them. I'm using Zola static site generator, and all I've done is make minor HTML and CSS tweaks, so I really have no idea what I'm doing where it concerns frontend presentation.

Give in to the noJS movement, there's no animation and it's a beautiful minimalistic site if you disable javascript

I'll also add that the "night mode" is obnoxious as hell anyway.

Inverted colours would've been _mostly fine._ Not great, but mostly fine, but instead, the author went out of their way to add this flashlight thing that's borderline unusable?

What the hell is this website?

This scheme _can_ be made to work in the context of Cargo. You can have all of:

* Absence of lockfiles

* Absence of the central registry

* Cryptographically checksummed dependency trees

* Semver-style unification of compatible dependencies

* Ability for the root package to override transitive dependencies

At the cost of

* minver-ish resolution semantics

* deeper critical path in terms of HTTP requests for resolving dependencies

The trick is that, rather than using crates.io as the universe of package versions to resolve against, you look only at the subset of package versions reachable from the root package. See https://matklad.github.io/2024/12/24/minimal-version-selecti...

Wasn’t the article suggesting that the top level dependencies override transitive dependencies, and that could be done in the main package file instead of the lock file?

You should not be editing your cargo.lock file manually. Cargo gives you a first-class way of overriding transitive dependencies.

Java is compiled, FYI.

I don't think anything about Go requires a central authority. You only need access to the sources of all your dependencies.

Go by default uses proxy.golang.org for speed/security, and sum.golang.org for sharing verification, but it works just fine without them.

I think trust in binary packages / no remote code execution is orthogonal to dependency selection.

Indirect require section in go.mod file is essentially a lockfile. Once decision is made by tool, it's codified for future builds.

One of the versions will be picked up. If that version doesn’t work, you can try another one. The process is exactly the same

nixpkgs shines especially bright in this exact scenario

Yeah, you have to bump stuff and use packages that are actually compatible. Like Rust. Which does not do the insane things that Maven does, that the post author is presumably advocating for.

> I've never seen something so egregious before

You should check how comments work on niconico.

I think the same blog used to show you the cursor position of every other reader on your screen. Surprised that's been removed.

Probably the only way to do this is to convert the gifs to an actual video, and add some js that will unpause/pause on mousein/mouseout and touchstart/touchend

So Tonsky's punishing us for leaving JavaScript enabled?

Note that the original article came across as there being no package unification. A later update said that versions would be selected "closest to the root".

I was speaking to that version of the article. There was no way to override transitive dependencies and no unification. When those are in the picture, the situation changes. However, that also undermines an argument of the article against SemVer

> But... why would libpupa’s author write a version range that includes versions that don’t exist yet? How could they know that liblupa 0.7.9, whenever it will be released, will continue to work with libpupa? Surely they can’t see the future? Semantic versioning is a hint, but it has never been a guarantee.

I'm sure this feature is a joke, not intended to be usable. It's a personal blog.

That was only in an update, not in the original text.

Is that what Go does? I always thought their module versioning system sounded well thought out (though I gave up on Go before they introduced it so I have no idea how well it works in practice).

And interpreted.

Some call transforming .java to .class a transpilation, but then a lot of what we call compilation should also be called transpilation.

Well, Java can ALSO be AOT compiled to machine code, more popular nowadays (e.g. GraalVM).

You can also do cargo update -p

The //indirect dependencies I believe are just there to track dependencies that are not in the project, or to help with caching: https://github.com/golang/go/issues/36460

In go 1.17 they were added so that project loading did not require downloading the go.mod of every dependency in the graph.

Consider a project like Kubernetes. Find a dependency whose domain name has lapsed, or might soon. Snipe it, replicate the original VCS, add a new malicious version under a new tag. Wait for someone to go get -u it.

This is pretty bad even today: If it goes unnoticed, it could lead to compromised binaries being released. However, it underscores design decisions related to the module system that helps to reduce the impact:

- Use of MVS means that even without a sum file, you still won't automatically download malware published in new versions.

- Use of a centralized proxy and sumdb by most of the ecosystem greatly reduces the likelihood that an attacker will attempt to change an existing version as it likely won't work and might result in detection instead.

- Lack of code execution in dependency fetching substantially reduces the odds of being able to compromise a developer machine. It doesn't make the problem a non-issue, but the prognosis is a ton better.

In NPM, if you don't have a lockfile, the version constraints will be resolved as you install dependencies. These version constraints are not necessarily deterministic, and installation can execute arbitrary code as the user. This is a pretty bad combination but there is a bit of relief because at least malware can be pulled from NPM when it is discovered... Which doesn't solve everything, but it's a lot better than nothing.

Anyway, that's why I don't consider these topics to be fully orthogonal. They do have some interplay.

The decision process is deterministic and requires no human input, it's only there for caching / speed, so it's not like a traditional lockfile. You can delete the indirect section and it will be reconstructed exactly as before.

So you need to test if the version worked yourself (e.g. via automated tests)? Seems better to have the library author do this for you and define a range.

It's maybe implied since Maven lets you do that (actually it uses the shallowest dependency, with the one listed first winning ties), but the thrust of the article seems to be roughly: "OMGWTFBBQ we can't use L2 with 0.7.9 if L1 was only tested with 0.7.9!" so I don't know how the author feels about that.

[edit]

The author confirmed that they are assuming Maven's rules and added it to the bottom of their post.

> They would be resolved by just picking the version 'closest to root', as explained in the article.

Which is going to lead to horrible issues when that library isn't compatible with all your other dependencies. What if your app directly depends on both L1 and L2, but L1 is compatible with L3 1.2 ... 1.5 while L2 is compatible with L3 1.4 ... 1.7? A general "stick to latest" policy would have L1: "L3==1.5", L2: "L3==1.7" (which breaks L1 if L2 wins). A general "stick to oldest compatible" policy would have L1: "L3==1.2", L2: "L3==1.4" (which breaks L2 if L1 wins).

The obvious solution would be to use L3 1.4 ... 1.5 - but that will never happen without the app developer manually inspecting the transitive dependencies and hardcoding the solution - in essence reinventing the lock file.

> It is, the app developers can just put in a direct dependency on the fixed version of L2. As mentioned earlier, this is the version that will be resolved for the project.

And how is that going to work out in practice? Is that direct dependency supposed to sit in your root-level spec file forever? Will there be a special section for all the "I don't really care about this, but we need to manually override it for now" dependencies? Are you going to have to manually specify and bump it until the end of time because you are at risk of your tooling pulling in the vulnerable version? Is there going to be tooling which automatically inspects your dependencies and tells you when it is safe to drop?

> This is the same even if you use a lockfile system. When you update dependencies you are explicitly updating the lockfile as well, so a bunch of transitive dependencies can change.

The difference is that in the lockfile world any changes to transitive dependencies are well-reasoned. If every package specifies a compatibility range for its dependencies, the dependency management system can be reasonably sure that any successful resolution will not lead to issues and that you are getting the newest package versions possible.

With a "closest-to-root" approach, all bets are off. A seemingly-trivial change in your direct dependencies can lead to a transitive dependency completely breaking your entire application, or to a horribly outdated library getting pulled in. Moreover, you might not even be aware that this is happening. After all, if you were keeping track of the specific versions of every single transitive dependency, you'd essentially be storing a lockfile - and that's what you were trying to avoid...

> I think most people in the reproducible build space would consider Maven an external uncontrolled input

In an academic sense, you're probably right.

In practice it turns out that this isn't an issue in 99% of cases. Yes, I have once run into a weird issue where Nexus was corrupted and it took some debugging, so it's not like it can't happen, but assuming you don't do anything weird, the assumption that Maven artifacts are immutable is fairly safe.

I'm not saying that lockfiles aren't technically superior or anything, but the failure modes are so rare that people usually don't bother (even in Gradle where lockfiles are technically supported).

You go into your pom.xml file (bunch of <dependency>) using a text editor and change the order.

The article and various comments in this same thread have explained why these are not real issues because the resolution process picks the version 'closest to root'.

Yes, you can, if you manually interact with it. Most people don't do that because why would you? You generally use it as a proxy for maven central and similar and to upload your own internal artifacts through maven-publish. I'm not sure if it's the standard setting, but Nexus should typically be configured to prevent you from overwriting non-snapshot versions.

> modern package manger (npm, cargo, ...) experience

Lol, the word "modern" has truly lost all meaning. Your list of "modern package managers" seems to coincide with a list of legacy tooling I wrote four years ago! https://news.ycombinator.com/item?id=29459209

> they usually refer to an upstream by hash

exactly the same thing as a lockfile

> if the package name and version combination already exists

I was talking about tags above, eg. "npm i react@next", and you can use tags in your package.json. npm allows you to republish them at will, and you can never force your users to use a specific version.

Of course there's no 0-risk version of any of this. But in my experience, bugs tend to get introduced with features, then slowly ironed out over patches and minor versions.

I want no security bugs, but as a heuristic, I'd strongly prefer the latest patch version of all libraries, even without perfect guarantees. Code rots, and most versioning schemes are designed with that in mind.

I don't understand why major.minor.patchlevel is a "hint". It had been an interface contract with shared libraries written in C when I first touched Linux, and that was 25+ years ago; way before the term "semantic version" was even invented (AFAICT).

It can't be a guarantee. Even the smallest patches for vulnerabilities change the behavior of the code. Most of the time this is not a problem, but weird things happen all the time. Higher memory usage, slower performance, some regressions that are only relevant for a tiny amount of users, ...

So you... manually re-lock the parts you need to?

> I've never seen something so egregious before

Streaming comments on YouTube give it a run for its money, what absolute garbage.

> If that version doesn’t work, you can try another one.

And how will this look like, if your app doesn't have library C mentioned in its dependencies, only libraries A and B? You are prohibited from answering "well, just specify all the transitive dependencies manually" because it's precisely what a lockfile is/does.

Alternative answer: both versions will be picked up.

It's not always the correct solution, but sometimes it is. If I have a dependency that uses libUtil 2.0 and another that uses libUtil 3.0 but neither exposes types from libUtil externally, or I don't use functions that expose libUtil types, I shouldn't have to care about the conflict.

> P.S. Sadly, I think enough people have left Twitter that it's never going to be what it was again.

Majority of those people came back after a while. The alternatives get near-zero engagement, so it's just shouting into the wind. For the ones that left over political reasons, receiving near-zero engagement takes all the fun out of posting... so they're back.

Maven is not Java, though.

Of course it's functionally lock files. They do the same thing!

There's a very strong argument that manually managing deps > auto updating, regardless of the ergonomics.

P.S. You're, right, but also it's where the greatest remnant remains. :(

"There is another tool that does exactly the job of a lockfile, but better."

vs

"You can use make to ape the job of dependency managers"

wat?

I think the difference is that since libraries do not specify version ranges, you must manually override their choices to find a compatible set of dependencies.

The solution is version ranges, but this then necessitates lockfiles, to avoid the problem of uncontrolled upgrades.

That said, there's an option that uses version ranges, and avoids nondeterminism without lockfiles: https://matklad.github.io/2024/12/24/minimal-version-selecti....

Note: maven technically allows version ranges, but they're rarely used.

When you are building some app in an ecosystem not entirely managed by you, things like this are bound to happen, so there are always ways to solve this.

You use Foo1 in Project1 (= one pom.xml) and create Project2 (=second pom.xml) where you use Foo2 (but package it in such a way that Foo2 is not exported from Project2), and depending on the usecase create a thin wrapper which you can then use from Project1, as an absolute worst case.

Then you sit and cry of course

Of course it is

After more than a decade of working on spring projects in fortune 500 companies, I've literally never had this problem with Maven dependencies.

I agree its theoretically possible, but I disagree that its difficult to resolve or somehow "hell". It works extremely well.

Except the only reason code "rots" is that the environment keeps changing as people chase the latest shiny thing. Moreover, it rots _faster_ once the assumption that everyone is going to constantly update get established, since it can be used to justify pushing non-working garbage, on the assumption "we'll fix it in an update".

This may sound judgy, but at the heart it's intended to be descriptive: there are two roughly stable states, and both have their problems.

Pretty much. Everything is a breaking change to someone. Best to just ignore sem ver and have a robust automated test suite and deployment process that minimises issues with a bad build.

Don't forget the part where Maven silently picks one version for you when there are transitive dependency conflicts (and no, it's not always the newest one).

Thankfully that can be collapsed.

Do you mean the live chat? Those are, appropriately, for live streams. They do replay afterwards as depending on the type of stream the video may not make complete sense without them (and they're easy enough to fold if they don't have any value e.g. premieres).

It's not "all the transitive dependencies". It's only the transitive dependencies you need to explicitly specify a version for because the one that was specified by your direct dependency is not appropriate for X reason.

Could aggregate the incrementing to for example 1 per day.

More often than not things are compatible within a major version. Very often things are compatible within a minor version.

Not being able to build because one thing depends on libpupa 1.2.34.pre5 and another, on 1.2.35 would be a worse outcome, on average.

Practically no one uses that.

The difference is that the data is centralized with a single source of truth, and you have tools for working with it automatically. It doesn't mean lockfiles are cheap to update, but it does mean it's a much more streamlined process when it's time.

you press a button which triggers a pipeline which does npm update on all root dependencies and produces a new lockfile, then creates a PR you need to approve. creating a PR triggers running all the tests you bothered to write to also flag things that didn't go well automagically.

Notably, a lockfile does not solve this problem either.

A single override does not equate to an entire lockfile of dependencies.

Imagine I make a library for loading a certain format of small, trusted configuration files.

Some guy files a CVE against my library, saying it crashes if you feed it a large, untrusted file.

I decide to put out a new version of the library, fixing the CVE by refusing to load conspicuously large files. The API otherwise remains unchanged.

Is the new release a major, minor, or bugfix release? As I have only an approximate understanding of semantic versioning norms, I could go for any of them to be honest.

Some other library authors are just as confused as me, which is why major.minor.patchlevel is only a hint.

Maven's version resolution mechanism determines which version of a dependency to use when multiple versions are specified in a project's dependency tree. Here's how it works:

- Nearest Definition Wins: When multiple versions of the same dependency appear in the dependency tree, the version closest to your project in the tree will be used.

- First Declaration Wins: If two versions of the same dependency are at the same depth in the tree, the first one declared in the POM will be used.

This points to a software best-practice: "Don't leak types from your dependencies." If your package depends on A, never emit one of A's structs.

Good luck finding a project of any complexity that manages to adhere to that kind of design sensibility religiously.

(I think the only language I've ever used that provided top-level support for recognizing that complexity was SML/NJ, and it's been so long that I don't remember exactly how it was done... Modules could take parameters so at the top level you could pass to each module what submodule it would be using, and only then could the module emit types originating from the submodule because the passing-in "app code" had visibility on the submodule to comprehend those types. It was... Exactly as un-ergonomic as you think. A real nightmare. "Turn your brain around backwards" kind of software architecting.)

Sure, I'm happy with locking the parts I need to lock. Why would I lock the parts I don't need to lock?

And yet, that one manual override and an auto-generated lockfile require basically the same level of effort, and serve the same purpose.

Edit: actually, depending on the package manager, the auto generated lockfile takes less work than the single override, as they don't have the same issue maven does to require an override in the first place.

True, but the lockfile is imposed at build time. Swapping out the version of a transitive dependency might build totally fine, but also might result is broken behaviour at runtime if the behaviour of the dependency changed.

> Imagine I make a library for loading a certain format of small, trusted configuration files.

> Some guy files a CVE against my library, saying it crashes if you feed it a large, untrusted file.

Not CVE-worthy, as the use case clearly falls outside of the documented / declared area of application.

> refusing to load conspicuously large files [...] Is the new release a major, minor, or bugfix release?

It deserves a major release, because it breaks compatibility. A capability that used to work (i.e,. loading a large but trusted file) no longer works. It may not affect everyone, but when assessing impact, we go for the most conservative evaluation.

JFC, get off Twitter. It's a Nazi propaganda site and you are going to be affected by that even if you think you're somehow immune.

The data is also centralized without lockfiles though...it's in the package spec file itself, where all version can be upgraded together. If you are saying the only difference is some tooling for automation, that's a temporary problem, not a fundamental one.

Is this a joke? What's the difference between this and pressing a button which triggers a pipeline which does npm update on all root dependencies and produces a new package.json file which you approve in a PR? Is the only difference that some convenient tooling already exists so you don't have to update each root dependency by hand?

I like this example.

The client who didn't notice a difference would probably call it a bugfix.

The client whose software got ever-so-slightly more reliable probably would call it a minor update.

The client whose software previously was loading large files (luckily) without issue would call it major, because now their software just doesn't work anymore.

I can think of plenty situations where you really want to use the dependency's types though. For instance the dependency provides some sort of data structure and you have one library that produces said data structure and a separate library that consumes it.

What you're describing with SML functors is essentially dependency injection I think; it's a good thing to have in the toolbox but not a universal solution either. (I do like functors for dependency injection, much more than the inscrutable goo it tends to be in OOP languages anyways)

Well, I guess this works if one appends their newly-added dependencies are appended at the end of the section in the pom.xml instead of generating it alphabetically sorted just in time for the build.

I'd be willing to bet that 95% of my "followers" on Twitter are bots. So I get near-zero engagement, or engagement that is worth zero.

Gradle suffers the same exact issue by default, because it inherits it from Maven (they use the same repository). You need to go out of your way to enable strict versioning policies and lock files.

Maven and Gradle make up the vast majority of all Java projects in the wild today. So, effectively, Maven is Java in terms of dependency management.

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.

Without a lock file your transitive dependencies are.... by definition not centralised?

Or have I misunderstood?

By "centralized" I mean a single file that contains all transitive dependency version information and nothing else. This is very different than having to recursively examine tiny portions of your dependencies' package specs recursively to find all transitive dependencies.

The difference is transitive dependences with ranges, which results in less frequent updates of direct dependences. And tooling of course too

A package spec defines your desires for your dependencies, a lockfile defines a resolution of those desires.

For example, as a developer I want Spring to stay on 6.3.x and not suddenly jump to 6.4 - as that is likely to break stuff. I do not care whether I get 6.3.1 or 6.3.6, as they are quite unlikely to cause issues. I do not care the slightest what version of libfoobar I get 5 dependencies down the line.

However, I do not want packages to suddenly change versions between different CI runs. Breakage due to minor version bumps are unlikely, but they will happen. That kind of stuff is only going to cause noise when a rebuild of a PR causes it to break with zero lines changed, so you only want version upgrades to happen specifically when you ask for them. On top of that there's the risk of supply chain attacks, where pulling in the absolute latest version of every single package isn't exactly a great idea.

The package spec allows me to define "spring at 6.3.x", the lockfile stores that we are currently using "spring 6.3.5, libfoobar 1.2.3". I ask it to look for upgrades, it resolves to "spring 6.3.6, libfoobar 1.4.0". There's also a "spring 6.4.0" available, but the spec says that we aren't interested so it gets ignored. All tests pass, it gets merged, and we'll stay at those versions until we explicitly ask for another upgrade.

The whole flow exists for things which aren't root dependencies. The major versions of those are trivial to keep track of manually, and you'll only have a handful of them. It's all the minor versions and downstream dependencies which are the issue: tracking them all manually is a nightmare, and picking whatever happens to be the latest version at time-of-build is a massive no-no.

It's also an almost-real situation (although I wasn't the library developer involved)

You can Google "YAMLException: The incoming YAML document exceeds the limit" - an error introduced in response to CVE-2022-38752 - to see what happens when a library introduces a new input size limit.

What happened in that case is: the updated library bumps their version from 1.31 to 1.32; then a downstream application updates their dependencies, passes all tests, and updates their version from 9.3.8.0 to 9.3.9.0

Maven pom.xml files are maintained by hand, not by some code generation tool.

I fear it says something unfortunate about our entire subculture if the greatest remnant remains at the Nazi bar. :(

(To be generous: it might be that we didn't build our own bar the moment someone who is at least Nazi-tolerant started sniffing around for the opportunity to purchas the deed to the bar. The big criticism might be "we, as a subculture, aren't punk-rock enough.")

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 can think of those situations too, and in practice this is done all the time (by everyone I know, including me).

In theory... None of us should be doing it. Emitting raw underlying structures from a dependency coupled with ranged versioning means part of your API is under-specified; "And this function returns an argument, the type of which is whatever this third-party that we don't directly communicate with says the type is." That's hard to code against in the general case (but it works out often enough in the specific case that I think it's safe to do 95-ish percent of the time).

If Twitter is a Nazi site then why do I have to block Laura Loomer & Ben Shapiro manually?

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.

It works just fine in C land because modifying a struct in any way is an ABI breaking change, so in practice any struct type that is exported has to be automatically deemed frozen (except for major version upgrades where compat is explicitly not a goal).

Alternatively, it's a pointer to an opaque data structure. But then that fact (that it's a pointer) is frozen.

Either way, you can rely on dependencies not just pulling the rug from under you.

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.

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.

I like this answer. "It works just fine in C land because this is a completely impossible story in C land."

(I remember, ages ago, trying to wrap my head around Component Object Model. It took me awhile to grasp it in the abstract because, I finally realized, it was trying to solve a problem I'd never needed to solve before: ABI compatibility across closed-source binaries with different compilation architectures).

> 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.

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

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

You can use version range with a maven plugin

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