First off, thanks for the awesome project @stephank! I'd like to propose an option to make the output of this tool slightly more easy maintain.
Looking at the generated yarn-project.nix, it seems like > 99% of it is taken by cacheEntries which is not meant to be reviewable, however the rest of it (< 1%) is fits in the opposite category - code that I'm likely to want to modify (e.g. the path to .yarn/releases is wrong, as I'm using nixExprPath to put place yarn-project.nix several levels deep from the root folder).
Can we change the behavior of the tool (e.g. having an opt-in option) so that the cacheEntreis are generated in a separate Nix file? (In thoery, it could even be a json file, if that's faster to parse than importing a Nix file.) That would be similar to how default.nix is generated (if flake.nix is not present).
First off, thanks for the awesome project @stephank! I'd like to propose an option to make the output of this tool slightly more easy maintain.
Looking at the generated
yarn-project.nix, it seems like > 99% of it is taken bycacheEntrieswhich is not meant to be reviewable, however the rest of it (< 1%) is fits in the opposite category - code that I'm likely to want to modify (e.g. the path to.yarn/releasesis wrong, as I'm usingnixExprPathto put placeyarn-project.nixseveral levels deep from the root folder).Can we change the behavior of the tool (e.g. having an opt-in option) so that the
cacheEntreisare generated in a separate Nix file? (In thoery, it could even be a json file, if that's faster to parse than importing a Nix file.) That would be similar to howdefault.nixis generated (ifflake.nixis not present).