| 17 Nov 2025 |
 dish [Fox/It/She] | i mean thats not necessarily true | 21:48:57 |
| dish [Fox/It/She] | theres a lot of packages that dont have lockfiles and thats why they haven't been repackaged | 21:49:24 |
| dish [Fox/It/She] | I'm going to go ahead and do this(draft until post-master branchoff so it'll make it to 26.05) | 23:48:34 |
| dish [Fox/It/She] | unless you're already working on it ^^ | 23:48:41 |
| 18 Nov 2025 |
| dish [Fox/It/She] | edit: nvm, made it myself | 01:39:49 |
| dish [Fox/It/She] | https://github.com/nixos/nixpkgs/pull/462749 | 01:40:06 |
| dish [Fox/It/She] | github's diff is screwed as always but its ~5k lines removed i think | 01:41:56 |
| dish [Fox/It/She] | yeah manual calculation and the real raw diff is +8,-4819 | 01:43:14 |
| dish [Fox/It/She] | also, node-packages.nix is under 1Mib! 919Kib left | 01:44:06 |
| dish [Fox/It/She] | * also, node-packages.nix is under 1Mib! 919Kib only! big news | 01:44:11 |
|  Hakase (she/her) joined the room. | 01:57:53 |
 Tomodachi94 (they/them) | Is this after accounting for the above PR? | 03:11:06 |
| dish [Fox/It/She] | yes | 03:11:14 |
| dish [Fox/It/She] | thats when looking at node-packages.nix on that PR's branch | 03:11:28 |
|  Yorusaka Miyabi joined the room. | 04:23:32 |
 dotlambda | In reply to @pyrox:pyrox.dev
theres a lot of packages that dont have lockfiles and thats why they haven't been repackaged There are plenty of packages with censored lock files. So that shouldn't have stopped people from repackaging | 06:54:51 |
| dish [Fox/It/She] | true, but I do not want every package still in nodePackages to be repackaged with an in-tree lockfile. Then we end up with a worse version of how it was before I started doing my debloat work, where we have megabytes and megabytes of generated inscrutible lockfiles in-tree. We need a better solution than vendoring, and until one is implemented, I do not want to package projects that do not wish to follow current best-practices | 07:02:13 |
| dish [Fox/It/She] | Hell, I've been working to remove those vendored lockfiles where I can, because they are in many cases solutions to problems that don't exist, or a symptom of using old tooling(such as mkYarnPackage) where using new tooling allows getting rid of giant vendored lockfiles and helps decrease nixpkgs' bloat(ref: #327064) | 07:04:04 |
| dish [Fox/It/She] | Let's consider how tomodachi94 mentioned above that awesome-lint's lockfile was 307Kb when generated. Considering how there are 44 packages in nodePackages on the master branch right now, if we moved all of those out and they all had the exact same lockfile size, that would be 13.5Mb of lockfiles. While yes, some would be larger and some would be smaller, my point is that this is a gigantic amount of generated data that does nothing but increase the download size of the nixpkgs tarball too much proportional to the amount of packages it adds to the set. Also, just 3 of those lockfiles would equal the entire 44-package set size right now on my reduced branch, and 10 would be the same size as the nodePackages set at its largest(when it had way over 100 packages!). Considering that, its frankly better to keep packages in nodePackages if the alternative is vendoring a lockfile, but my opinion is to just drop any that do not have a lockfile if upstream rejects having one. | 07:16:11 |
| dish [Fox/It/She] | Hope that makes sense, and sorry for the ramble | 07:16:17 |
| dish [Fox/It/She] | * Let's consider how tomodachi94 mentioned above that awesome-lint's lockfile was 307Kb when generated. Considering how there are 44 packages in nodePackages on the master branch right now, if we moved all of those out and they all had the exact same lockfile size, that would be 13.5Mb of lockfiles. While yes, some would be larger and some would be smaller, my point is that this is a gigantic amount of generated data that does nothing but increase the download size of the nixpkgs tarball too much proportional to the amount of packages it adds to the set. Also, just 3 of those lockfiles would equal the entire 37-package set size right now on my sindresorhus removal branch, and 10 would be the same size as the nodePackages set at its largest(when it had way over 100 packages!). Considering that, its frankly better to keep packages in nodePackages if the alternative is vendoring a lockfile, but my opinion is to just drop any that do not have a lockfile if upstream rejects having one. | 07:21:04 |
| dotlambda | I totally agree. I was only arguing in favor of removal, not in favor of vendoring more lock files | 07:41:08 |
 Cobalt | Regarding the earlier discussion of lockfiles, how feasible would it be to extend the existing tooling for importNpmLock to pnpm? | 11:46:41 |
| Cobalt | I might be looking at having to support pnpm soon-ish and would rather write some rust then go back to FODs | 11:46:41 |
|  Lyn changed their display name from Fugi to Lyn. | 13:37:46 |
| dish [Fox/It/She] | I'd rather extend prefetch-npm-deps since that's the tooling used with buildNpmPackage | 17:26:12 |
| dish [Fox/It/She] | and that doesn't require importing and parsing lockfiles | 17:26:20 |
| dish [Fox/It/She] | though you mention rust so I assume you mean prefetch-npm-deps | 17:26:38 |
| Cobalt | I'm not too sure what's used under the hood. Iirc didn't rust tooling power the lockfile parsing for importNpmLock? | 17:27:18 |
| Cobalt | One of my primary goals was avoiding FOD, I. E., npmDepsHash and friends in favor of using the lockfile. And also disaggregating dependencies | 17:28:49 |
