| 28 May 2023 |
|  hellwolf joined the room. | 13:29:10 |
| hellwolf | Hey y'all! Let's say I pick a rfew nodePakcages e.g "nodePackages.three|mathjax", what would a one liner say using nix-shell where then I can run node and require("three")? | 13:34:44 |
 Lily Foster | I think we would need setup hooks that set NODE_PATH. Which actually would probably be a good idea to add to the nodejs derivation | 13:41:51 |
| Lily Foster | Hmmm if I remember later I'll experiment with adding that | 13:42:18 |
| hellwolf | Okay. Something similar to haskellPackages.ghcWithPackages would be handy, say:
nix-shell -p 'nodejsPackages.nodeWithPackages { pkgs: [ pkgs.three ] } ?
| 14:06:45 |
| Lily Foster | Well it would be something like nodejs.withPackages probably but also nodePackages is gonna go away and/or be redone before that's viable... | 14:08:49 |
| hellwolf | I see.
I don't think it's too big a stretch to proposing the Nth package manager for NodeJS ecosytem, after now pnpm. | 14:10:06 |
| hellwolf | I think Nix has the potential to be the right one :) | 14:10:19 |
| hellwolf | But still need that Nth nix node builder though too. | 14:10:54 |
| hellwolf | Or is buildNpmPackage targeting that? | 14:11:25 |
| hellwolf | * Or is buildNpmPackage targeting that role? | 14:11:27 |
| Lily Foster | buildNpmPackage is really more for leaf-like application-level npm packages | 14:12:03 |
| Lily Foster | At some point we may end up trying to build out a real Nix-based node package set, but npm dependencies go really deep. Unlike how other package sets like python generally are | 14:14:08 |
| Lily Foster | So I doubt it'll really be worth it tbh | 14:14:23 |
| Lily Foster | We'll probably aim for more like how the rust stuff works | 14:14:35 |
| Lily Foster | I want to have something like importCargoLock but for package-lock.json but it's far down on the backburner rn | 14:15:12 |
| hellwolf |
npm dependencies go really deep.
Indeed. I wonder if it's inherit to node, or just how npm/yarn works.
| 14:21:15 |
| Lily Foster | In reply to @hellwolf:matrix.org
npm dependencies go really deep.
Indeed. I wonder if it's inherit to node, or just how npm/yarn works.
Tbh just how any similar system works. See Mix/Elixir, Rust/Cargo, Go, etc. Those don't go as deep as npm but they do get large | 14:23:00 |
| hellwolf | I see. | 14:45:41 |
| hellwolf | One more question, when using buildNpmPackage packages. do packages still share the build outputs of their dependencies if possible? | 14:46:12 |
| Lily Foster | In reply to @hellwolf:matrix.org
One more question, when using buildNpmPackage packages. do packages still share the build outputs of their dependencies if possible? How do you mean exactly? | 15:01:56 |
| Lily Foster | Like sharing dependency sources? | 15:02:07 |
| hellwolf | Like not having the same thing in the nix store twic | 15:04:32 |
| hellwolf | * Like not having the same thing in the nix store twice | 15:04:33 |
| Lily Foster | (If so, the answer is no because it's all cache FODs from the lockfiles. If there was something like importCargoLock then those would be I suppose by nature of how Nix works but until computed derivations you don't want to use that in nixpkgs mostly) | 15:04:50 |
| Lily Foster | In reply to @hellwolf:matrix.org
Like not having the same thing in the nix store twice Yeah no, given it generates npm caches for all deps as a single FOD. The amount of dedup that would do is probably not as much as you're expecting but one day it'll be able to do that | 15:05:51 |
| hellwolf | do you think auto-optimise-store = true will do some extra magic still? | 15:07:12 |
| Lily Foster | Good question. Probably? I forget how exactly that determines what to hard link but I suppose it will | 15:08:09 |
| Lily Foster | Due to the way npm's cacache works | 15:08:27 |
|  Yuu Yin left the room. | 20:31:26 |
