| 18 Nov 2025 |
 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 |
| 20 Nov 2025 |
|  John joined the room. | 06:25:28 |
 Emma [it/its] | hm, is there a helper to trim down build artifacts in node_modules? | 18:26:55 |
| Emma [it/its] | trying to trim down the size of a node derivation and just deleting .o, .a etc files helps a lot | 18:29:05 |
| dish [Fox/It/She] | nope afaik | 18:34:49 |
| Emma [it/its] | argh okay, guess ill be enumerating filetyes myself - is it possible to match multiple extensions with find? | 18:35:40 |
