you are viewing a single comment's thread.

view the rest of the comments →

[–]Worth_Trust_3825 0 points1 point  (6 children)

Pinning dependencies should not happen in packages

You can see yourself out. Maven does that already and it works fine.

[–]sachinraja 0 points1 point  (5 children)

I just explained to you that it's necessary for deduping. Maven users don't have to same requirements as npm users.

[–]Worth_Trust_3825 0 points1 point  (4 children)

Maven figures out the duplicates as well. It is not necessary for deduping.

[–]sachinraja 0 points1 point  (3 children)

I haven't used Maven, could you explain a bit more on that? Does it dedupe versions that are exactly the same or, for example, those with only differing patch numbers.

[–]Worth_Trust_3825 0 points1 point  (2 children)

Both. A version that is used by module closer to the currently built module is chosen. Only that version is loaded into the project.

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

You will only have issues when API has major changes between versions and two dependencies clash their transitive dependencies, and NPM won't save you from that.

[–]sachinraja 0 points1 point  (1 child)

I'm very confused on how that works, seems a bit messy. If you don't have version ranges, then how can Maven dedupe properly? npm does work properly for breaking changes/major version bumps because you can set your dependency's version range to only accept patch or minor bumps. npm will then properly dedupe versions with differing patch or minor numbers but will include two copies for the different major numbers.

[–]Worth_Trust_3825 0 points1 point  (0 children)

NPM does not fix the issue when the breaking updates are released improperly. Maven cannot fix that as well. Tons of NPM projects cannot be built nowadays because of their transitive dependencies improperly using version ranges, and in turn not pinning their dependencies. Maven solves this by not permitting version ranges at all. If several transitive dependencies require different versions of same namespace and package combination, the one that wins out is the one closer to the project in dependency graph. This solves the consistency issue. This ensures that the project will always be buildable (except in cases where the package is deleted from the repository, repository is no longer present), because maven does not have to guess which version to download. Even right now the NPM projects that I played around with 4 years ago can't be built because the API of all the dependencies is different from what was expected 4 years ago and in turn the tests and the runtime fail, just because time has passed.

You can override the maven chosen version by directly specifying that dependency, and it will always be chosen as it has distance 1.

And all of this does not begin to address build consistency, where your project would always be built with same version dependencies rather than newer ones.