package-lock.json

[rom1504]

Hi,
I just discovered that package-lock.json is not transitive :
https://docs.npmjs.com/files/package-lock.json

One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package. It shares a format with npm-shrinkwrap.json, which is essentially the same file, but allows publication. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.

That was my main critic about package-lock.json : I was afraid to have to update all the libs to get an updated version of dependent lib. But actually this is not the case.

package-lock.json is only used when a package is used directly.

I know you tried package-lock.json for a while @feross and you decided against it.

Did you have any other reason than that problem ?

[KayleePop]

This is related https://yarnpkg.com/blog/2016/11/24/lockfiles-for-all/

It's about the yarn lockfile, but the same logic applies to the package-lock.json

[DiegoRBaquero]

The only scenario I find in useful in the context of WebTorrent is if MAYBE we have to reproduce something caused by dependencies. But it has never happened. Rarely anyone runs npm install while webtorrent being the top level, that's mostly us contributing, and we are fine without it.

[rom1504]

I'm not sure if yarn.lock is exactly the same because afaik it is transitive (and published to npm unlike package-lock.json) so you do have to update the lock files all the time. The usefulness for webtorrent (and any lib) is 1. Tests on the ci will behave the same as a local clone 2. People cloning webtorrent and trying some examples in the repo will have the exact same versions as master. It's mostly a question of reliability and reproducibility : any commit can be retested in the exact same condition than when it was committed because the version are set precisely in the package lock. So it means that if someone does a commit and guarantees that it works for him, it will work for any other people using that same commit. That's for the benefits. The drawback for me was having to update the lock all the time in every module if I wanted to have updated modules in a top level app/package. But this is actually not needed thanks to the property I mentioned at the beginning and so it isn't a drawback at all.

…

On Wed, May 16, 2018, 05:59 Diego Rodríguez Baquero < ***@***.***> wrote: The only scenario I find in useful in the context of WebTorrent is if MAYBE we have to reproduce something caused by dependencies. But it has never happened. Rarely anyone runs npm install while webtorrent being the top level, that's mostly us contributing, and we are fine without it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1392 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPN_lpoX5-o-_elDpQ5Radd6tSddpTpks5ty6Q1gaJpZM4UAQdD> .

[rom1504]

The file that is transitive and can be published to npm (and hence shouldn't be used by libs but only top level applications) is shrinkwrap. That could be used by webtorrent-desktop and cli so users have the correct version when doing a global install of these apps. (Although I think it isn't very useful for webtorrent desktop since it's already distributed as an archive containing all the packages in precise versions) Basically package-lock.json is for development while shrinkwrap.json is for users. https://docs.npmjs.com/files/shrinkwrap.json And https://docs.npmjs.com/files/package-lock.json Are pretty informative about these 2 files.

…

On Wed, May 16, 2018, 09:32 Romain Beaumont ***@***.***> wrote: I'm not sure if yarn.lock is exactly the same because afaik it is transitive (and published to npm unlike package-lock.json) so you do have to update the lock files all the time. The usefulness for webtorrent (and any lib) is 1. Tests on the ci will behave the same as a local clone 2. People cloning webtorrent and trying some examples in the repo will have the exact same versions as master. It's mostly a question of reliability and reproducibility : any commit can be retested in the exact same condition than when it was committed because the version are set precisely in the package lock. So it means that if someone does a commit and guarantees that it works for him, it will work for any other people using that same commit. That's for the benefits. The drawback for me was having to update the lock all the time in every module if I wanted to have updated modules in a top level app/package. But this is actually not needed thanks to the property I mentioned at the beginning and so it isn't a drawback at all. On Wed, May 16, 2018, 05:59 Diego Rodríguez Baquero < ***@***.***> wrote: > The only scenario I find in useful in the context of WebTorrent is if > MAYBE we have to reproduce something caused by dependencies. But it has > never happened. Rarely anyone runs npm install while webtorrent being > the top level, that's mostly us contributing, and we are fine without it. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#1392 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACPN_lpoX5-o-_elDpQ5Radd6tSddpTpks5ty6Q1gaJpZM4UAQdD> > . >

[feross]

Here's my philosophy:

package-lock.json is for top-level apps, not for packages. If you use it inside a package it will only confuse you when you run npm install and get different (locked) dependencies than your users get when they run npm install package-name.

As @DiegoRBaquero says, one possible advantage of package-lock.json for modules is that it documents which set of dependencies we know to work (in case a dependency suddenly causes our tests to start failing). However, I haven't found this useful in practice.

[feross]

I'm closing this issue since there's no bug to fix here, but feel free to continue discussion! ✨