| 18 Nov 2025 |
 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 |
| Cobalt | This about a custom flake, but regardless if that is an IFD than it might not be a good fit for nixpkgs | 17:40:07 |
| dish [Fox/It/She] | nix-update can update stuff from flakes :3 | 17:40:27 |
| dish [Fox/It/She] | nix-update --flake packageName | 17:40:35 |
| Cobalt | * | 17:40:33 |
| Cobalt | Ik, didn't work in our stuff reliably ;) | 17:40:51 |
| dish [Fox/It/She] | damn | 17:41:17 |
| dish [Fox/It/She] | wasn't sure if you did know, since a lot of folks dont know about that flag ^^ sorry abt that | 17:41:34 |
| Cobalt | NP, when we tried FOD we also only found it very late | 17:46:09 |
| Cobalt | But regardless, if FOD is better for eval time then it might be worth a revisit | 17:46:29 |
| Cobalt | Thank you for the helpful and quick responses | 17:47:05 |
| dish [Fox/It/She] | In reply to @c0ba1t:matrix.org
But regardless, if FOD is better for eval time then it might be worth a revisit yeah my thought is just that thousands of unique derivations, even if de-duped across packages, is still more derivations and memory usage even when unused, and therefore eval perf impact | 18:27:08 |
