Hacker News Reader

Comment by horsawlarway | Hacker News Reader

This is a great example of chesterton's fence.

The author of this piece doesn't understand why a top level project might want control of its dependencies dependencies.

That's the flaw in this whole article, if you can't articulate why it's important to be able to control those... don't write an article. You don't understand the problem space.

Semantic versioning isn't perfect, but it's more than a "hint", and it sure as hell beats having to manually patch (or fork) an entire dependency chain to fix a security problem.

View on HN

I think people forget NPM added package-lock.json for the npm@5 release that was rushed out the door to match the next node.js major and was primarily to cut down on server traffic costs as they weren't making money from the FOSS community to sustain themselves.

Author puts up Maven as an example of no lockfiles. Maven does allow a top-level project to control its transitive dependencies (when there is a version conflict, the shallowest dependency wins; the trivial version of this is if you specify it as a top-level dependency).

I think rather that the author doesn't realize that many people in the lockfile world put their lockfiles under version control. Which makes builds reproducible again.

Yes, but Maven doesn't support reproducibility (outside of plugins that basically haul in a lockfile). So his whole point is moot (Gradle now does, as an aside: https://docs.gradle.org/current/userguide/dependency_locking...)

Again - I don't think the author is aware enough of the problem space to be making the sort of claim that he is. He doesn't understand the problem lockfiles are solving, so he doesn't know why they exist and wants them gone... chesterton's fence in action.

---

Directly declaring deps is great. It's so great that we'd like to do it for every dependency in many (arguably most) cases. But doing that really sort of sucks when you start getting into even low 10s of deps. Enter... lockfiles and the tooling to auto-resolve them.

>Maven doesn't support reproducibility

I don't think that is true:

https://maven.apache.org/guides/mini/guide-reproducible-buil...

Caveats from that document, top one basically blows this whole thing up.

Maven can't give you reproducible builds with version ranges, because it has no lockfile.

---

More Details Reproducible Builds for Maven:

Require no version ranges in dependencies, Generally give different results on Windows and Unix because of different newlines. (carriage return linefeed on Windows, linefeed on Unixes) Generally depend on the major version of the JDK used to compile. (Even with source/target defined, each major JDK version changes the generated bytecode) For detailed explanations, see Maven “Reproducible/Verifiable Builds” Wiki page.

I would say that is a reasonable constraint. As you know, version ranges, and other "dynamic" versions in Maven are inherently incompatible with reproducible builds because they are resolved non-deterministically during the build. The most common approach when reproducibility is required is to resolve dynamic dependency versions in source, which is a strategy shared by tools that use lockfiles.

I agree that Maven would be better with lockfile support. However, as with any proposed evolution of Maven, I can imagine it would be quite hairy to implement in a way that is compatible with other mechanisms.

On the other listead caveats, I would add:

- Output line endings are controllable via line.separator, which Maven honors. Input line endings are an important consideration for reproducibility, but also not truly a problem of Maven's reproducibility.

- JDK version can be enforced with Maven Enforcer and/or toolchains.

Reply on news.ycombinator.com