Open delroth opened 1 year ago
Our tooling still won't actually work with yarn-berry yet, even if it did parse the lockfile. I do want proper yarn-berry support soon though, given a lot of things are starting to use it now
not technically maintainer I think, but you touched it last :p
No I'm not technically maintainer, but unless someone else steps up I'm probably going to be the one to add yarn-berry support to our tooling anyway 🙈
Yeah, I hacked around to add YAML parsing support and found out that there's (unsurprisingly) a lot more things to fix, and I'm very out of my depth with 0 knowledge of that ecosystem unfortunately :) Thank you!
i looked into this more with some digging into the yarn codebase and it seems like we've got a few issues:
resolution
key instead of a URL, in the format of name@protocol:version
, (ex. @aashutoshrathi/word-wrap@npm:1.2.6
) so we have to construct the URL to download ourselvesthis is possible to fix but imo the better solution would be to find some way to use yarn cli to do the actual fetching and validation because this is much more complicated
UPDATE: the checksum thing is ridiculous. i did some testing and yes, changing the compression level in the yarn config will change the hashes of every single lockfile entry, or fail if --immutable is passed.
the default compress level is 0, so it's not like this will always break...
i'm leaning towards just running yarn install --immutable --mode skip-scripts
instead of reimplementing their own logic but worse. i'm not entirely sure why we don't always just do that, i think it's probably because we operate off of only the lockfile and yarn itself requires the presence of a package.json as well.
EDIT: bug report submitted upstream here: https://github.com/yarnpkg/berry/issues/6068
i'm not entirely sure why we don't always just do that
We need to use a format that's guaranteed to be stable across different versions of Yarn.
If builtins.fromYaml
(NixOS/nix#7340) gets merged, would it be possible to use the hashes from yarn.lock
directly and get rid of other sort of vendor hashs?
I don't see us using fromYAML
any time soon even if it was merged tomorrow because it'd break eval with old versions of Nix.
I don't see us using
fromYAML
any time soon even if it was merged tomorrow because it'd break eval with old versions of Nix.
Not sure about the process to determine when to use a built-in function, but it's sensible to wait at least until the stable branch-off after it hits Nixpkgs.
There's a sizable chunk of users still on nix 2.3. I don't see a good reason to break eval for them. And if it has to be polyfilled anyway, then we don't even need to wait for the PR merge to do so.
I'm not sure if this checks off all the stability requirements for nixpkgs
, but if you need to package something for personal use, you can do something like this:
@delroth Why was this closed?
Still an issue.
Turns out you can make the deps reproducible between (non-windows) platforms by predefining the list of supported architecture like so:
supportedArchitectures = builtins.toJSON {
os = [ "darwin" "linux" ];
cpu = [ "arm" "arm64" "ia32" "x64" ];
libc = [ "glibc" "musl" ];
};
configurePhase = ''
# ...
yarn config set supportedArchitectures --json "$supportedArchitectures"
'';
This makes it download all platform/architecture specific dependencies. I updated the example in my previous comment.
Describe the bug
When trying to get
fetchYarnDeps
to consume theyarn.lock
from Grafana (https://github.com/grafana/grafana/blob/main/yarn.lock), it dies with a parsing error:I suspect that this is because it's a new-style yarn.lock file using the YAML syntax, and not the old "custom" syntax. The yarnpkg-lockfile npm package can't parse it for that reason.
Notify maintainers
cc @lilyinstarlight (not technically maintainer I think, but you touched it last :p)