Commit lockfile for consistent CI and installs

[uncenter]

Lockfiles exist to guarantee consistency across installs, especially in CI tests! This is a fresh lockfile from a fresh clone and install, and all tests are passing.

[zachleat]

What are the drawbacks to checking in the lockfile?

• Minor updates in dependencies must be opted into at the project level, right?
• Increase in source conflicts

Others?

[uncenter]

Minor updates in dependencies must be opted into at the project level, right?

Can you elaborate?

Increase in source conflicts

Sure, but that's easily resolved and doesn't outweigh the benefits of consistent package versioning in different environments.

[Aankhen]

What are the drawbacks to checking in the lockfile?

• Minor updates in dependencies must be opted into at the project level, right?

• Increase in source conflicts

Others?

That seems like a fair summary. I’d like to emphasize for clarity that all changes to dependencies must be explicit, whether minor or major, upgrade or downgrade, etc. I agree with uncenter that conflicts in lockfiles are generally trivial to resolve, especially outside a monorepo, but that’s certainly a non-zero cost that should be considered.

(As for the more general question, I’m entirely on the side of committing it.)

[zachleat]

My primary concern is (unless I’m mistaken) that checking in a lockfile makes Eleventy the bottleneck when dependencies issue updates (especially for security reasons). Numerous times over the years we’ve had deps issue updates and they are subsequently automatically picked up via minor releases without any action on my part.

This is a huge benefit.

[zachleat]

#3293 (comment) is one such recent issue

[Aankhen]

Numerous times over the years we’ve had deps issue updates and they are subsequently automatically picked up via minor releases without any action on my part.

I agree that that’s an advantage, but conversely, apart from introducing non-determinism, it adds a new vector for security issues in the form of malicious updates from the developers of those dependencies. That may not be a major concern, of course, since malicious developers are exceedingly unlikely compared to security issues that are fixed by later releases.

[zachleat]

After a bit more research I learned that I am misinformed about one small but important point: the package-lock.json file is never part of the published package code so “Minor updates in dependencies must be opted into at the application level” is not accurate.

More accurately, minor updates in dependencies would need to be opted into in this repo only, which makes a lot more sense now that we have dependabot enabled here.

So, let’s roll with this for a bit and see how annoying it is 😅

[zachleat]

Shipping with 3.0.0-beta.2 and 3.0.0-alpha.19

[paulshryock]

Yay for dependency hygiene.

The next step is to also pin (at least dev) dependencies, and then upgrade those pinned dependencies regularly on purpose (instead of by accident).

https://docs.renovatebot.com/dependency-pinning/#pinning-dependencies-and-lock-files

[uncenter]

Big fan of Renovate myself! GitHub's Dependabot is the other option, though I found it cumbersome at times.