| 18 Nov 2025 |
 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 |
| dish [Fox/It/She] | why would you want to do that? The main benefit of using a FOD is that we avoid a decently large performance penalty associated with having to parse all the lockfiles | 17:30:48 |
| dish [Fox/It/She] | * why would you want to do that? The main benefit of using a FOD is that we avoid a decently large performance penalty associated with having to parse lockfiles | 17:30:52 |
| dish [Fox/It/She] | also importNpmLock and not using FODs requires IFD or vendoring the lockfile iirc since you need the package-lock.json to be able to be parsed | 17:32:53 |
| dish [Fox/It/She] | so since it requires vendoring... I'm against it | 17:33:08 |
| dish [Fox/It/She] | * so if it requires vendoring... I'm against it | 17:33:43 |
| Cobalt | It doesn't actually require vendoring, sometimes lockfiles need some hashes fixed but that's it (and there's an script packaged in nixpkgs for this) | 17:35:49 |
| dish [Fox/It/She] | that's good! good to know | 17:36:21 |
| dish [Fox/It/She] | but why do you want to avoid fods here? I still don't understand that | 17:36:37 |
| Cobalt | More cumbersome to update, | 17:37:21 |
| Cobalt | And aggregated npm deps | 17:37:29 |
| dish [Fox/It/She] | i mean if you're using npmDepsHash then nix-update takes care of it automatically | 17:37:55 |
| dish [Fox/It/She] | the aggregated npm deps.. you mean doing like one derivation per node_module? | 17:38:12 |
| dish [Fox/It/She] | * the aggregated npm deps.. you mean doing like one derivation per node_modules package? | 17:38:50 |
| Cobalt | Yes, that's roughly what it produces for. It reduces downloads from npm a lot | 17:39:19 |
| dish [Fox/It/She] | that definitely sounds good from a reducing bloat perspective | 17:39:46 |
