| 13 Nov 2023 |
 @ambroisie:belanyi.fr | Oooh 👀 | 22:58:53 |
 Lily Foster | ah yes, the classic "i'll reply later" a few months ago (oops....) | 22:59:09 |
| Lily Foster | forgot about that | 22:59:12 |
| @ambroisie:belanyi.fr | Turns out I'm already subscribed to the MR, I'd just forgotten it existed... :') | 23:00:56 |
| 14 Nov 2023 |
 szucsitg | Ah this looks nicer than yarn2nix 🤔 | 04:13:02 |
| szucsitg | I spent several hours Lily Foster to figure out why yarn2nix doesn't work. I get to a state where it's functioning, there was multiple problems:
- messing with configurephase screwed me over
- workspace module build didn't build properly because they referred to each other (multiple layers of mess) and without it module package resolution doesn't work, it has to be mapped manually
- modules still didn't build because I didn't input the package resolution to the derivation
Now it's a state when it can build selected modules even referencing each other, but yarn.lock is too big, and because of that any module build is 10 minutes due to very slow fixupPhase and eating up too much space. I cannot find anything that how could I exclude them from derivation, it wants to build a module for each packaging regardless of shared offlinecache. Nor I wasn't able to turn off fix up. So unless you have some any other idea, I gave up on this for now 😕 i also tried to add yarn.lock to each module but it’s not maintable either. Anyway, I just wanted to thank you for your kind help 🙂 | 12:33:19 |
| Lily Foster | In reply to @szucsitg:matrix.org
I spent several hours Lily Foster to figure out why yarn2nix doesn't work. I get to a state where it's functioning, there was multiple problems:
- messing with configurephase screwed me over
- workspace module build didn't build properly because they referred to each other (multiple layers of mess) and without it module package resolution doesn't work, it has to be mapped manually
- modules still didn't build because I didn't input the package resolution to the derivation
Now it's a state when it can build selected modules even referencing each other, but yarn.lock is too big, and because of that any module build is 10 minutes due to very slow fixupPhase and eating up too much space. I cannot find anything that how could I exclude them from derivation, it wants to build a module for each packaging regardless of shared offlinecache. Nor I wasn't able to turn off fix up. So unless you have some any other idea, I gave up on this for now 😕 i also tried to add yarn.lock to each module but it’s not maintable either. Anyway, I just wanted to thank you for your kind help 🙂 what's it trying to do during fixup? if it's just taking a while to strip stuff you could dontStrip = true; on the derivation | 12:57:49 |
| Lily Foster | also i'm glad you figured out at least those problems! sorry i didn't end up being more helpful 😅 | 12:58:03 |
| szucsitg | Thanks, dontstrip does made it much faster. Also I figured out that I had the unlink error I just forgot to mention due to parallel writes to cache. Unfortunately I ran into another issue. Infinite recursion... My colleagues made circular dependency between workspace modules 😅 | 13:49:07 |
| Lily Foster | In reply to @szucsitg:matrix.org
Thanks, dontstrip does made it much faster. Also I figured out that I had the unlink error I just forgot to mention due to parallel writes to cache. Unfortunately I ran into another issue. Infinite recursion... My colleagues made circular dependency between workspace modules 😅 oof | 13:49:49 |
| Lily Foster | idk how yarn or yarn2nix does peer dep handling | 13:50:00 |
 @joepie91:pixie.town | yarn 1.x treats peer dependencies as optional dependencies; it does not automatically install them, and just produce a warning if they are missing. this is what used to be the behaviour of npm as well. I don't know if newer Yarn versions have changed this | 13:51:37 |
| @joepie91:pixie.town | * yarn 1.x treats peer dependencies as optional dependencies; it does not automatically install them, and just produces a warning if they are missing. this is what used to be the behaviour of npm as well. I don't know if newer Yarn versions have changed this | 13:51:43 |
| Lily Foster | In reply to @joepie91:pixie.town
yarn 1.x treats peer dependencies as optional dependencies; it does not automatically install them, and just produce a warning if they are missing. this is what used to be the behaviour of npm as well. I don't know if newer Yarn versions have changed this but it otherwise does the circular resolution okay? i figure it's probably a yarn2nix bug anyway (there seems to be no shortage of those, unfortunately...) | 13:52:32 |
| @joepie91:pixie.town | I think circular dependencies are undefined behaviour in JS modules? | 13:54:36 |
| @joepie91:pixie.town | not sure how Yarn handles those in general actually | 13:54:45 |
| @joepie91:pixie.town | typical peer dependency use would involve one 'primary' package and a bunch of eg. plugin packages that peer-depend on that primary package; I've never really seen peer dependencies used outside of plugin architectures like that | 13:55:23 |
| @joepie91:pixie.town | so that wouldn't be circular, exactly | 13:55:43 |
| Lily Foster | yeah i suppose they're not designed to be circular, but i thought they were designed to be used in scenarios that otherwise might be circular, like plugin deps | 13:57:30 |
| Lily Foster | idk i need coffee anyway and brain is not working well yet | 13:57:45 |
| Lily Foster | (i'd definitely trust your judgement way more than my own on this anyway) | 13:58:46 |
| szucsitg | I checked the code they really cross-referenced the project while not even declaring the module in package.json 🙄🤦♂️ | 13:59:51 |
