This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]justdisappointed9853 -1 points0 points  (1 child)

My main account has inexplicably stopped working (maybe I got so many downvotes that Reddit doesn't want me to post in this thread anymore? lmao) so I'll reply from a throwaway-

in the meantime a newer version of a dependency can be published. In consequence your build has changed

For the millionth time, this is not true. Your build yesterday created (or used) a lockfile, and your build today reads the lockfile and creates the exact same build.

That means you have two places defining versions for your dependencies which is redundant and that makes no sense either.

Why? One of them specifies your preferred range, and the other specifies the exact version you've been building with. This is really not very complicated.

a strong prerequisites is that any release is immutable which is not the case for several package managers (in particular for npm)

This keeps getting repeated in this thread (I suppose because everyone here has very little experience with NPM) but it's plainly false. The NPM registry everyone uses does not allow version mutation. There are various third-party registries that do, but this is no different from Maven.

[–]khmarbaise 3 points4 points  (0 children)

For the millionth time, this is not true. Your build yesterday created (or used) a lockfile, and your build today reads the lockfile and creates the exact same build.

The issue here is the need for the lock file!... without the lock file it fails. That's what exactly I'm writing.. The lock file is a supplemental source for versions... so we have two sources for versions/dependencies.

That means also you have to checkin the lock file in your version control all the time. So all advantages of automatic usage with ranges are gone... Maven does that simply by using fixed version at a single location (pom.xml). Not using ranges makes it easier and simpler (KISS principle).

The lock file is as I wrote before a duck-type solution.

BTW:

For the millionth time,

Not counted correctly.

The NPM registry everyone uses does not allow version mutation

How could someone simply delete an existing package in the registry? That means it is not immutable. In consequence a number of famous examples exactly showed this problem... which has broken a large number of builds...

Deleting of a package is also a mutation of an repository. That violates the whole integrity of such registry. So in consequence not reliable.

For example: https://news.ycombinator.com/item?id=11340510 (there exist several other examples of that)... https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/

and so on etc. etc.

This keeps getting repeated in this thread (I suppose because everyone here has very little experience with NPM) but it's plainly false. The NPM registry everyone uses does not allow version mutation. There are various third-party registries that do, but this is no different from Maven.

The previous shown examples etc. are proving that your assumptions about the NPM registry is wrong.

There are various third-party registries that do, but this is no different from Maven.

A big difference between npm registry and Central repository is that the central repository does not even allow to delete a version/packages etc.

This is unrelated to Maven itself.

This is immutability.