Closed alxndrsn closed 4 months ago
Having some kind of lockfile is useful for developers. (Not to mention… CI.) Translate to package-lock.json?
As noted in #157, lockfiles are useful by default for applications but intentionally not used for most libraries. npm will obey a lockfile in a dependency. We want to test with the latest matching dependency according to the range in the package, not lock. Nor do we want to lock all the dependencies and have to release an update to this package on each new dependency version.
There's a tradeoff here and it's not necessarily wrong to lock library dependencies. But it's not typically the npm way and especially inconvenient for a meta package like this that wires up several smaller packages for complex types.
As noted in #157, lockfiles are useful by default for applications but intentionally not used for most libraries. npm will obey a lockfile in a dependency.
It sounds like you’re referring to npm-shrinkwrap.json. yarn.lock/package-lock.json aren’t published; in a library, they serve to make the full development state for a given revision reproducible.
Ah right:
The difference is that package-lock.json cannot be published, and it will be ignored if found in any place other than the root project.
Still, the point stands that it doesn't seem lockfiles are actually solving a problem here, and more likely creating one.
https://github.com/sindresorhus/ama/issues/479#issuecomment-310661514
They solve the problem I mentioned (which pg has been affected by, notably), and their absence isn’t really a solution to the problem sindresorhus mentioned back in 2017 (dependabot is more reliable). Almost the opposite, really: if you run npm update
and things suddenly stop working, being able to diff the lockfile because it’s in version control makes for an easy way to know exactly what changed.
Anyway, not that big a deal one way or another for this repo – I’m used to reconstructing dependency trees for a point in time by now. Just wanted to get accurate information out there.
Right, the GHA addition is overdue and very valuable. I understand that lockfile benefits apply to library developers. Unlike applications, there's a real tradeoff to be considered. I'm unpersuaded that libraries having lockfiles is the right default. Tooling has improved since in the last 5 years but the need to configure and operate it is still extra work.
Definitely not something to sneak in alongside other changes. If someone wants to do the work to run tests both with and without a lockfile in GHA I'm happy to review that PR.
Definitely not something to sneak in alongside other changes.
The lockfile was introduced in https://github.com/brianc/node-pg-types/pull/152, and mentioned clearly in the PR description.
A build without yarn.lock
can be seen at https://github.com/alxndrsn/node-pg-types/actions/runs/8408288755/job/23024258952#step:3:19; I include the logs here:
"Sneak" is the wrong word, but ultimately there was an unrelated change (using Yarn) proposed that didn't need to be, which then necessitated another unrelated change (a lockfile). The GHA workflow is an unqualified improvement, thank you! There's more discussion/work needed on the lockfile and I don't have the time to devote to that right now.
yarn is no longer used in CI, so yarn-specific config files are no longer required.