| 18 Dec 2023 |
 Wanja Hentze | here's my view:
- npmlock2nix: worked okay, but undermaintained and never got lockfile v3 support
- buildNpmPackage (from nixpkgs): works fine, but needs prefetching. makes one big derivation for deps and is thus slow for small dep changes
- dream2nix: too complicated, couldn't get it to work
- floco: too complicated, couldn't get it to work
- adisbladis' buildNodeModules: worked great and looks simple, needs no prefetcher. is very very alpha stage software though
| 08:58:55 |
| Wanja Hentze | things I've yet to check out: serokell/nix-npm-buildpackage, napalm | 09:00:34 |
| *  @adis:blad.is should put buildNodeModules in nixpkgs | 09:07:12 |
| Wanja Hentze | do ittt | 09:08:12 |
 Sandro 🐧 | Didn't it require to always commit package.json or the lock file to do IFD? | 13:06:58 |
| Sandro 🐧 | If it is without IFD or coming lock files and really just works, we should just use it for everything. We shouldn't really have multiple ways to build things if one thing is superior | 13:07:40 |
| Wanja Hentze | yes it does | 13:08:50 |
| Wanja Hentze | the asymmetry here is from nixpkgs-internal vs. external use | 13:09:05 |
| Wanja Hentze | for external stuff that's consuming nixpkgs, having the package.json and package-lock.json committed is actually totally fine | 13:09:34 |
| Wanja Hentze | now, should nixpkgs export packaging helpers that it doesn't even want to use for itself? maybe, maybe not | 13:10:17 |
| Wanja Hentze | fwiw I'm kinda salty that poetry2nix got removed because it wasn't used internally anymore. | 13:10:57 |
| Wanja Hentze | downstream repos have their own lockfiles committed anyway. but they might want to update deps more often, so an expensive prefetch step is more of a problem than it is for nixpkgs | 13:12:52 |
| Sandro 🐧 | In reply to @whentze:matrix.org
fwiw I'm kinda salty that poetry2nix got removed because it wasn't used internally anymore. It got removed because it was broken after the bootstrapping changed and it wasn't fixed for some time | 13:47:58 |
| Sandro 🐧 | Also vendoring other git repos into the tree is mäh | 13:48:16 |
| Sandro 🐧 | In reply to @whentze:matrix.org
for external stuff that's consuming nixpkgs, having the package.json and package-lock.json committed is actually totally fine But it is really, really fat | 13:48:50 |
| Sandro 🐧 | We can't just xz compress them and then commit them? 😅 | 13:49:12 |
| Wanja Hentze | I think you're misunderstanding me | 13:49:29 |
| Wanja Hentze | I'm not saying let's commit a bunch of lockfiles to nixpkgs | 13:49:41 |
| Wanja Hentze | the use case is "I have a nodejs project and my lockfile is already in git, I want to write a default.nix" | 13:50:28 |
| Wanja Hentze | this has nothing to do with nixpkgs other than that it would be nice to get the packaging helper function from nixpkgs | 13:51:48 |
| Wanja Hentze | hence me asking "is it worthwhile to ship packaging helpers in nixpkgs that are not dogfooded by nixpkgs?" | 13:53:33 |
| Sandro 🐧 | Maybe depends on size but e.g. vendoring yarn2nix seemed more of a headache then it needs to be. Other things are just put in as a CLI is that's possible | 15:15:05 |
| Wanja Hentze | oh wait | 15:16:02 |
| Wanja Hentze | you're talking about vendoring the packaging helper, not the packages | 15:16:15 |
| Wanja Hentze | in this case, it's really not a ton of code: https://github.com/adisbladis/buildNodeModules | 15:16:46 |
| 19 Dec 2023 |
| @adis:blad.is | We could port over the expressions that already vendor a lock file.
No point in having fat FODs for those cases. | 02:51:09 |
| @adis:blad.is | In reply to @whentze:matrix.org
in this case, it's really not a ton of code: https://github.com/adisbladis/buildNodeModules If I were to add it to nixpkgs I'd consider it the new upstream and archive my repo | 02:53:19 |
| 20 Dec 2023 |
| Sandro 🐧 | In reply to @adis:blad.is
We could port over the expressions that already vendor a lock file.
No point in having fat FODs for those cases. for remote building it is likely still faster. Copying hundreds of derivations over is extremely slow and takes probably longer than rebuilding them. | 02:20:59 |
 Mason Mackaman | anyone have experience wrangling vite? | 02:37:36 |
| @adis:blad.is | In reply to @sandro:supersandro.de
for remote building it is likely still faster. Copying hundreds of derivations over is extremely slow and takes probably longer than rebuilding them. That's only true if you're privileged enough to have a fast Internet connection.
That's not true for users in the developing world. | 06:31:58 |
