#Yarn workspaces doesnt detect mine install#
You had to manually run any build steps and install phases which was the largest gap to fill. This worked if you were willing to compose these tools together, but it wasn’t a “works out of the box” solution. I had a large collection of utilities to convert NPM or Yarn locks, and even package.json with non-conflicting descriptors into my “structured inputs” and I even supported workspaces. I previously was able to convert arbitrary NPM URIs to Nix fetchers, I could also create module trees with linked bins as either node_modules/ or “global” style installations given structured inputs. You can almost directly feed a package-lock.json into fetchTree which has an enormous performance impact compared to nixpkgs.fetch*.
Suffice to say that NPM package-lock.json and flake.lock and “flakeref” URIs are “almost directly compatible” which I’ve been leveraging with a lot of success. But until then I’ll just advise you to “just use NPM with locks and registry packages” if you can, because most existing tools were designed with that in mind. I’m excited to show off what I’ve been working on soon. If you manage a larger project you can cut hours long cache initializations down to a few minutes, with a flexible UX for local dev AND CI which is missing from existing tools. Nix’s caching system and built-in fetchers give it a notable performance boost. It’s got performance issues because of filesystem IO but aside from that I can’t gripe about it too much. Yarn is more workable with CA hashing but honestly you’ll be pulling your hair out dealing with the dozens of other poor design decisions and bugs that throw a wrench in reproducible builds. It’s fucking malware in my opinion - and I only say this after digging around its internals for several weeks. There are notable aspects of their telemetry “feature” which consume an inordinate amount of disk space and time after v2, parts of which appear to be intentionally obfuscated to mask the extent of Facebook’s data collection even with telemetry disabled you still suffer the runtime costs of collection, you only prevent reporting ( that is until you invoke yarn with telemetry enabled at which point they send the entire backlog… ). I would strongly suggest that you avoid building large projects with Yarn, and bear in mind that you should not try to include any part of yarn’s global cache in a build output - this will poison your closure. The inline comments explaining the rationale behind randomly generated seeds was based on an incorrect understanding of how filesystem synchronization works ( cough websh*ts cough ). I wrestled with Yarn extensively and did have “some success” with PnP but before you get too excited you need to know - Yarn’s caches and hashing systems are non deterministic and are fundamentally incompatible with Nix’s approach to building.įrankly Yarn “berry” is poorly implemented, and I found that it produces massive numbers of redundant tarballs because the core hashing system is based on randomly generated seeds. Yes I have been down this rabbit hole for about three months and am about to release a new flake based package manager for Node.js. That way, while developing, the modules would always match the commit you’re on.
Ideally, this could be integrated with direnv so that just having the yarn.lock change results in the pnp being built automatically.
#Yarn workspaces doesnt detect mine how to#
I looked at yarn2nix but it doesn’t seem to handle PnP repos yet.ĭid anybody look at Yarn PnP yet and have ideas on how to integrate this with Nix? It seems to me that most Node.js applications are reasonably trivial to convert to Yarn PnP, and with PnP being such a close match with Nix that would result in stronger better faster Nix builds? In other words, the Node.js module system goes from “slightly deranged” to “very similar to Nix”. The modules can now be built without requiring their dependencies be part of the build. This is nice for disk space of course, but also for install speed and reproducibility, there’s a lot of hashing and caching going on. So I recently found out that yarn has a PnP mode which overrides Node.js’s standard resolution mechanism (to node_modules directories) and instead references a read-only compressed store of packages. an npm v2 lock file, you just put dream2nix in flake.nix and you’ll have a devshell and build with the correct modules, no extra step. UPDATE: dream2nix creates node_modules from the lock files directly, if the lock file has all the necessary info.
0 kommentar(er)
