| 14 Nov 2025 |
 dish [Fox/It/She] | today in cursed JS stuff: angular-cli is built with bazel but still uses pnpm to manage JS dependencies | 02:31:22 |
| dish [Fox/It/She] | also its bazel version is too new for nixpkgs atm so we need to wait for 7.7.0 to get merged for it to build :) | 02:32:41 |
 Tomodachi94 (they/them) | Sorry for the delay. Totally! | 15:04:36 |
| dish [Fox/It/She] | In reply to @tomodachi94:matrix.org
Sorry for the delay. Totally! all good! all of them have gone through now but if I ever have more in the future I'll let you know ^^ | 15:51:56 |
| 16 Nov 2025 |
| Tomodachi94 (they/them) | Happy to review any sort of PR that reduces technical debt, broadly speaking | 04:59:45 |
| 17 Nov 2025 |
|  n3tcat changed their profile picture. | 01:20:56 |
 dotlambda | Should we update nodePackages once before branch-off? | 01:31:16 |
| dish [Fox/It/She] | maybe? I would rather keep it frozen since the set is deprecated but since I'm not doing any work on it for the time being then i have no merge conflict complaints if you do so | 02:31:45 |
| dish [Fox/It/She] | though if updating the set drops the LoC then I'd be in favor I suppose | 02:32:18 |
| dotlambda | In reply to @pyrox:pyrox.dev
though if updating the set drops the LoC then I'd be in favor I suppose I assume it would | 03:42:04 |
| 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 |
