| 18 Nov 2025 |
 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 |
