I did. And working on package managers is part of my daily job, so it's not the first time I think about this.
My thread is a good explanation of the problems in your reasoning, and I'd be happy to go into more details if you have a specific point you'd like to challenge.
I am not advocating against using package-lock.json for programs designed to be consumed by the end consumer. I do suggest not to use lock files in packages that will be dependencies of other packages.
I have read comments of the multiple people who are suggesting to use package-lock.json because it locks down dev dependencies. This is not a valid use case for the same reasons that I outline in the article. If you need to lock down dev dependencies, use semver range that meets your requirements.
If you need to lock down dev dependencies, use semver range that meets your requirements
Exact semver range isn't locking. Transitive dependencies are still free to change unless you use a proper lockfile.
This isn't to say that exact dependencies are useless (some of my codebases use them), but they solve a different problem and it shouldn't impact at all whether the lockfiles are meant to be committed or not.
I am not advocating against using package-lock.json for programs designed to be consumed by the end consumer
This is the part I'm objecting to. To quote myself:
A lockfile isn't meant to prevent breakages [for consumers] - it's to ensure smooth deployments and development cycles. The first isn't super relevant to libraries and tooling, but the second very much is.
I understand your argument (using lock files ensures smooth deployments and development cycles). However, unlike others in this thread, I do not put as much value on this argument compared to the downsides I have described in this article. In practise, I have found it extremely rare that dependencies or transitive dependencies break or introduce bugs within semver changes that prevent me from working or that would have been prevented using lock files. Happened, maybe 3 times over the last 5 years that my work was interrupted for longer than an hour.
I did. And working on package managers is part of my daily job, so it's not the first time I think about this.
My thread is a good explanation of the problems in your reasoning, and I'd be happy to go into more details if you have a specific point you'd like to challenge.
I am not advocating against using package-lock.json for programs designed to be consumed by the end consumer. I do suggest not to use lock files in packages that will be dependencies of other packages.
I have read comments of the multiple people who are suggesting to use package-lock.json because it locks down dev dependencies. This is not a valid use case for the same reasons that I outline in the article. If you need to lock down dev dependencies, use semver range that meets your requirements.
Exact semver range isn't locking. Transitive dependencies are still free to change unless you use a proper lockfile.
This isn't to say that exact dependencies are useless (some of my codebases use them), but they solve a different problem and it shouldn't impact at all whether the lockfiles are meant to be committed or not.
This is the part I'm objecting to. To quote myself:
I understand your argument (using lock files ensures smooth deployments and development cycles). However, unlike others in this thread, I do not put as much value on this argument compared to the downsides I have described in this article. In practise, I have found it extremely rare that dependencies or transitive dependencies break or introduce bugs within semver changes that prevent me from working or that would have been prevented using lock files. Happened, maybe 3 times over the last 5 years that my work was interrupted for longer than an hour.
It could have been 0 times, if you used a lockfile. Just saying.