crane VS dream2nix

i would also recommend using crane or naersk since iirc rustPlaform.buildRustPackage can mangle some of these options (or maybe i just did something wrong lol)

Notably crane is doing what cargo-chef is doing for Nix.

I don't think it's very valid to compare the two. It is a little bit just to compare the experiences using them bit they aren't meant to solve the same set of issues. In fact, they are better together in my experience. I use nix to manage my terraform configurations with a lot of success. It reduces my boilerplate and helps me build abstractions on top of HCL.

If you ever decide to take a stab at nix again, consider looking at https://github.com/ipetkov/crane and using flakes. I've got it down to the point that I can get a new rust project set up with nix in about 30 seconds with linting, package building, and test running all in the checks

Take a look at Crane, though it is squarely aimed at non-beginners. If you want to submit whatever you're packaging to nixpkgs and not just for personal use, you can't use crane, though.

To get Rust incremental builds, did you consider using something such as crane https://github.com/ipetkov/crane ?

And regarding OCI images, i built nix2container (https://github.com/nlewo/nix2container) to speed up image build and push times.

This is the relevant part of my flake (which uses the quick-start template of crane):

I imagine/hope you've seen this, but over in Rust-land I do something similar using https://github.com/ipetkov/crane. I've been on the lookout for something precisely like this for a while. I don't know much about the newer versions of yarn but imagined such a thing was possible. I am looking forward to trying this out, especially if the above is eventually addressed.

If you haven't already, I recommend checking out crane for building extensible workflows using cargo and Nix (e.g. running clippy, cargo-audit, cargo-nextest, cargo-tarpaulin, etc.)

(I'm on the flox team) we'd love to support that and it's something we've talked about! We already support auto-generation for some languages like Rust because they have a lockfile (e.g. Cargo.lock), but it's a bit trickier for a requirements.txt. We hope at some point to contribute to/integrate with upstream efforts like dream2nix which have auto-generation as their goal

How about dream2nix? I like to use the nix way, but there are many third nix ways

I'm not 100% sure, but looking at the docs [here](https://nix-community.github.io/dream2nix/subsystems/node.html#granular-pure-default) and the implementation [here](https://github.com/nix-community/dream2nix/tree/main/src/subsystems/nodejs/builders/granular-nodejs) it seems as it builds dependencies separately and symlinks (see `install-deps.py` those into a `node_modules` tree. I don't know much about Yarn's PNP (was doing more backend/devex last few years), but it sounds vaguely similar in that each package should be built once as a separate derivation and then symlinked to a big `node_modules`-as-a-symlink-tree derivation?

How are you building your NodeJS project with Nix right now? Recently I spot a new abstraction, it looks good but I havn't tried it yet: https://github.com/nix-community/dream2nix

dream2nix is a great package, that makes a nix-derivation out of node project with the minimal flake

The DavHau/dream2nix project aims to be a generic solution for this issue by splitting the problem into specific stages, each of which can be configured individually (e.g., changing the level of purity)