package-lock.json actually needed?

[JKRhb]

When adding or updating dependencies, I got the impression that package-lock.json sometimes causes problems if it isn't handled with care. From what I've learned over the last couple of months, lock files are not recommended for libraries but only for actual applications which require a certain set of exact dependencies to ensure that they always work.

As you could also fixate the version of a dependency by not using the ^ or ~ prefix, I wanted discuss removing the lock file again which would have the benefit of "automatic" updates for patch releases of dependencies. It would also make it more efficient to use node-wot besides other modules that have the same dependencies but slightly different versions in their package.json files.

Do you see any real benefits for the package-lock.json file? Or would it make sense to remove it?

[danielpeintner]

One the one hand, in the past we run into issues that even minor changes of libraries broke the tests etc. (see #379 or #395)
Moreover, with package-lock.json one can make sure that the build/test on GitHub actions etc are using exactly the same version.

On the other hand I see your arguments also.

Having said that, I find it also confusing that we need to update 2 different files (package-lock.json and package.json) to change a version.

My personal take is that IF we can live without package-lock.json I would be happy 👍

@relu91 @egekorkan opinions?

[egekorkan]

I would prefer to keep it to not have those headaches again. The only disadvantage I see is the need to add another file to the commit right? My answers to some arguments:

As you could also fixate the version of a dependency

I think the problem persists when dependencies themselves do not fix the version. (Not super sure about this)

the benefit of "automatic" updates for patch releases of dependencies.

I think I did not understand this one.

It would also make it more efficient to use node-wot besides other modules that have the same dependencies but slightly different versions in their package.json files.

But if I download a nodewot package as an npm dependency, its dependencies are not installed with the lock file versions right?

Having said that, I find it also confusing that we need to update 2 different files (package-lock.json and package.json) to change a version.

Two things about this.

1. We can fix/publish the lock version only at releases. Until the release, it is a "dangerous time".
2. No manual effort needed for the lock file right?

[JKRhb]

Thank you for your responses! I think what I had in mind was this issue comment: sindresorhus/ama#479 (comment) Here they argue that you should not use a package-lock.json for libraries as you would not notice that a dependency is broken due to the fixed versions -- users that depend on the library, however, would in fact notice it as npm ignores all lockfiles but the top-level one. Using dependabot, for example, could limit the occurrence of broken dependencies, though.

[egekorkan]

That issue is a nice thread where the opposing opinion is also presented (in a yarn article). So I am not sure since I find both side's arguments quite valid.

[relu91]

I would vote for keeping it, as sadly we are depending on libraries that do not strictly follow semver (argh 😞 ) not having the package-lock would cause painful debugging of what is happing in the CI. Plus don't forget that node-wot is also a CLI tool that is quite similar to an application.

I agree with want has been said in the YARN article:

First, it’s not going to be every user that is affected by this. It’s well agreed upon that applications should be using lockfiles, and if they are then they won’t be affected by sudden breaking changes.

Furthermore, managing the lock file is not a big deal when you use the right npm commands and never manually edit the package.json. Libraries can be added with npm add and the version can be changed using npm version. In these cases, the lock file is automatically updated. When there are version conflicts if you use npm install [--package-lock-only] which most of the time just works.

In conclusion, I would keep it.

[JKRhb]

I think you made some good arguments, @relu91. I would then propose closing this issue and keeping the lock file :)