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)

@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 🙈)

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

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 🙂

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 🙂

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 😅

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

perhaps there are circular plugin architecures, but usually it's more something like

const thing = require("thing");
const thingPluginA = require("thing-plugin-a);
const thingPluginB = require("thing-plugin-b");

let instance = thing({ plugins: thingPluginA, thingPluginB });

and so both the "core" package and the plugin packages are loaded from the application code, the plugins don't load the core and the core doesn't load the plugins, the peer dependency constraint just serves to give people a warning if they have an incompatible core and plugins in the same project

perhaps there are circular plugin architecures, but usually it's more something like

const thing = require("thing");
const thingPluginA = require("thing-plugin-a");
const thingPluginB = require("thing-plugin-b");

let instance = thing({ plugins: thingPluginA, thingPluginB });

and so both the "core" package and the plugin packages are loaded from the application code, the plugins don't load the core and the core doesn't load the plugins, the peer dependency constraint just serves to give people a warning if they have an incompatible core and plugins in the same project

I wonder if it's possible to just install a list of dependencies https://github.com/svanderburg/node2nix#adding-unspecified-dependencies , like having a package.json

 [
  "floomatic"
]

npm update doesn't work so I think not. My original issue is that right now I need to use export NODE_PATH="${pulumiSdks}/lib/node_modules/PKG_NAME/lib/modules" while my package has 0 source code, it's just a compilation of dependencies (same package.json as my original)