| 17 Nov 2025 |
 Tomodachi94 (they/them) | What's the best way to approach packaging a Node CLI project that doesn't have a lockfile? There's one in nodePackages that I would love to migrate over and start maintaining but I'm not sure what best-practice is | 03:42:28 |
 dotlambda | One argument in favor is that we might inadvertently have some vulnerabilities in the current package set | 03:42:46 |
| dotlambda | In reply to @tomodachi94:matrix.org
What's the best way to approach packaging a Node CLI project that doesn't have a lockfile? There's one in nodePackages that I would love to migrate over and start maintaining but I'm not sure what best-practice is Ask upstream to add a lock file | 03:43:16 |
| dotlambda | If we absolutely have to keep the package, I guess we have to vendor package-lock.json | 03:43:43 |
| Tomodachi94 (they/them) | I'll ask upstream first. The package in question is awesome-lint | 03:47:35 |
 dish [Fox/It/She] | sindresorhus hates lockfiles for some reason, good luck getting him to put one in any of his projects | 03:50:12 |
| dish [Fox/It/She] | wish he wouldnt cuz it would make a LOT of the nodePackages set disappear | 03:50:44 |
| dish [Fox/It/She] | * wish he did have lockfiles cuz it would make a LOT of the nodePackages set disappear | 03:50:58 |
| Tomodachi94 (they/them) | He wrote a very famous thing about how lockfiles are for "apps, not CLIs"... which makes his stance very confusing | 03:53:14 |
| dish [Fox/It/She] | In reply to @tomodachi94:matrix.org
He wrote a very famous thing about how lockfiles are for "apps, not CLIs"... which makes his stance very confusing yeah I've never understood that stance | 03:53:34 |
| dish [Fox/It/She] | especially since it costs him nothing to maintain a lockfile | 03:53:45 |
| dish [Fox/It/She] | frankly npm should remove the option to disable package-lock.json generation | 03:54:25 |
| dish [Fox/It/She] | though then it just gets added to gitignore and i get sad | 03:54:46 |
| Tomodachi94 (they/them) | I'm thinking about maybe having a nix-community repo for storing lockfiles of projects that don't like them... then we can do fetchurl from the repository maybe? | 03:55:25 |
| Tomodachi94 (they/them) | (I feel like maybe this, or something like it, has been proposed before somewhere?) | 03:56:12 |
| dish [Fox/It/She] | In reply to @tomodachi94:matrix.org
I'm thinking about maybe having a nix-community repo for storing lockfiles of projects that don't like them... then we can do fetchurl from the repository maybe? RFC 0191 by yours truly 😉 | 03:56:15 |
| dish [Fox/It/She] | i need to work on that more though | 03:56:28 |
| dish [Fox/It/She] | just been burnt out on that front, but I think it would overall be a good thing | 03:56:44 |
| dish [Fox/It/She] | also frankly i want to unify the JS dependency fetchers (fetchNpmDeps, fetchYarnDeps, pnpm.fetchDeps, and the new fetchDenoDeps) cuz theres too much divergence between them | 03:57:57 |
| dish [Fox/It/She] | one's rust(npm), one's js(yarn1), two use the upstream package manager(pnpm, yarnBerry) and one is a TS/Rust hybrid(deno) | 03:59:02 |
| dish [Fox/It/She] | and we dont even have bun yet(though that is also being worked on?) | 03:59:21 |
| Tomodachi94 (they/them) | I'm going to check how big the generated lockfile ends up being. If it's pretty small it might commit it? | 03:59:26 |
| dish [Fox/It/She] | * also frankly i want to unify the JS dependency fetchers (fetchNpmDeps, fetchYarnDeps, pnpm.fetchDeps, and the still in PR fetchDenoDeps) cuz theres too much divergence between them | 04:00:00 |
| Tomodachi94 (they/them) | As for lockfile maintenance for applications: my opinion is that lockfiles don't need to be updated on every single change, but definitely do it right before a release... but unfortunately this is not Sorhus' opinion | 04:00:49 |
| dish [Fox/It/She] | oh yeah if ur updating ur lockfile constantly thats an issue | 04:01:16 |
| dish [Fox/It/She] | cuz then you just have constant merge conflicts | 04:01:39 |
| dish [Fox/It/She] | In reply to @tomodachi94:matrix.org
I'm going to check how big the generated lockfile ends up being. If it's pretty small it might commit it? fine to commit to nixpkgd if its small, but considering the number of deps it has listed im skeptical | 04:04:14 |
| dish [Fox/It/She] | * <mx-reply><blockquote><a href="https://matrix.to/#/!NhAsaYbbgmzHtXTPQJ:funklause.de/$xBdgzYhGxTCUBRIj8B3BJNlm-M_VCjTGCKiXnqwea2k?via=pyrox.dev&via=matrix.org&via=nixos.dev">In reply to</a> <a href="https://matrix.to/#/@tomodachi94:matrix.org">@tomodachi94:matrix.org</a><br />I'm going to check how big the generated lockfile ends up being. If it's pretty small it might commit it?</blockquote></mx-reply>fine to commit to nixpkgs if its small, but considering the number of deps it has listed im skeptical | 04:04:25 |
| dish [Fox/It/She] | * <mx-reply><blockquote><a href="https://matrix.to/#/!NhAsaYbbgmzHtXTPQJ:funklause.de/$xBdgzYhGxTCUBRIj8B3BJNlm-M_VCjTGCKiXnqwea2k?via=pyrox.dev&via=matrix.org&via=nixos.dev">In reply to</a> <a href="https://matrix.to/#/@tomodachi94:matrix.org">@tomodachi94:matrix.org</a><br />I'm going to check how big the generated lockfile ends up being. If it's pretty small it might commit it?</blockquote></mx-reply>fine to commit to nixpkgs if its small, but considering the number of deps it has listed in node-packages.nix im skeptical | 04:04:40 |
| Tomodachi94 (they/them) | 308 kB... so pretty big | 04:06:10 |
