| 13 Nov 2023 |
 @ambroisie:belanyi.fr | Anyways, thanks for the confirmation 👍️ | 22:53:00 |
 Lily Foster | i'm getting motivation to make it since the more i look at pnpm, the less hellish it seems | 22:53:10 |
| @ambroisie:belanyi.fr | * I'm just waiting for buildPnpmPackage for this specific package, we're really in a https://xkcd.com/2347/ situation there for now | 22:53:14 |
| Lily Foster | which the same cannot have been said for npm | 22:53:15 |
| @ambroisie:belanyi.fr | I've been out of cycles lately to properly shave the yak, but yeah recent discussions on that issue have been very promising | 22:53:55 |
| Lily Foster | yeah i feel the low-on-cycles bit | 22:55:01 |
| Lily Foster | (i've been able to surprisingly do some stuff of late, but i haven't been able to choose what i am capable of working on and it's mostly been to distract from life stuff 🙈) | 22:55:24 |
| @ambroisie:belanyi.fr | In reply to @lily:lily.flowers
(i still want to yeet yarn2nix into the abyss at some point once we have mature and modern yarn tooling) What's the most proper way to do yarn packaging at the moment? I thought the last part of yarn2nix was the fixup_yarn_lock (or is it the one with dashes?) that's in a bunch of packages | 22:56:28 |
| * @ambroisie:belanyi.fr In reply to @lily:lily.flowers
(i've been able to surprisingly do some stuff of late, but i haven't been able to choose what i am capable of working on and it's mostly been to distract from life stuff 🙈) sends internet accolades | 22:56:57 |
| Lily Foster | In reply to @ambroisie:belanyi.fr
What's the most proper way to do yarn packaging at the moment? I thought the last part of yarn2nix was the fixup_yarn_lock (or is it the one with dashes?) that's in a bunch of packages well i finally got the new fixup stuff in, so someone just needs to dust off https://github.com/NixOS/nixpkgs/pull/210814 now | 22:58:40 |
| @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 |
