Should we gitignore package-lock.json?

[LeaVerou]

For packages that are dependencies of other packages (such as Color.js), I'm not sure there is much value in committing package-lock.json. Should we just remove it from the repo?

cc @lloydk @facelessuser @MysteryBlokHed @jgerigmeyer

[lloydk]

I'd prefer to keep it because it ensures that developers are using the same versions of the development dependencies.

What are the downsides?

[facelessuser]

Yeah, if there is no adverse effect, I don't see a reason to not include it.

[LeaVerou]

If we want to restrict dependencies to specific versions we could always tighten the requirements in package.json. It seems to defeat the purpose to have ranges there, then enforce specific versions via package-lock.json (and can be wasteful as it creates more redundancy).

Some more context here: https://dev.to/gajus/stop-using-package-lock-json-or-yarn-lock-3ddi

[kleinfreund]

While you can control the versions of directly listed dependencies, the lock file allows you to also lock the versions of indirect/transient dependencies. It's not uncommon that an update in such a dependency causes issues in a project which is then harder to reproduce and also to avoid without resorting to overriding such faulty versions. With a lock file, this is much more transparent and safe.

On the other hand, lock files tend to, over time, hold on to long outdated indirect dependency versions making it sometimes (though not commonly) necessary/helpful to regenerate the lock file. However, that's a smaller problem than those lock files fix in my opinion.

[43081j]

the various blog posts/opinions around not having a lockfile are pretty much all pointing out that the dependencies you install when developing a library are not the same as the ones consumers will pull down (since consumers of a library don't use the library's lock file).

this is true, but meanwhile it is extremely useful that all contributors have the same dev setup

you could disable usage of the lockfile in CI so you're still testing against what a user would see. but that has its own downsides too - since contributors will have a different dependency tree to CI

given whatever you decide has a downside, i'd just flip a coin to be honest 😅

[facelessuser]

As far as I'm aware, all of Color.js's dependencies are dev dependencies, so I'm not sure the user issue is even coming into the equation. Color.js has no dependencies for user use as far as I know.

[43081j]

very good point

in that case, we should keep it for sake of having better dx for contributors imo