Yarn only uses the "resolutions" field in the top-level package.json
file of a workspace. While it has been taken into account for
mkYarnWorkspace (9801e6e53d), it has not
been fixed for mkYarnPackage yet, which also uses the yarn workspace
mechanism under the hood.
A bit of care was needed because we don't want to introduce any IFD.
Projects often require a specific major version of NodeJS, and sometimes
a specific yarn version. Since yarn2nix utilities are accessed from
nixpkgs now, there is no simple way to override versions of nodejs and
yarn without complex solutions like an overlay.
This adds `yarn` and `nodejs` as optional attribute arguments to
`mkYarnModules`, `mkYarnPackage`, and `mkYarnWorkspace`. They default to
the same versions that are currently being used, and the nodejs input to
yarn is overridden so that it will match if only `nodejs` is overridden
by the user.
These arguments will also cascade from `mkYarnWorkspace` ->
`mkYarnPackage` -> `mkYarnModules`, making per-package overrides very
simple.
Nix supports md5, sha1, sha256, and sha512 hashes. The first two are
deprecated, but many npm packages provide only a sha1, so we have to
allow that one. This commit continues to leverage `ssri` for reliable
integrity string parsing and algorithm selection, but limits it to only
supported hash algorithms.
It also switches the hash representation in the generated nix file to
base64, since that format is supported by nix (suggested by jtojnar).
This saves a little disk space and computation.
Finally, it adds a .prettierignore file, since prettier called with the
arguments in the format command currently tries to format node_modules.
Some NPM packages provide multiple integrity hashes with different
algorithms. These are space separated, like below:
```
tar@^4:
version "4.4.19"
resolved "https://registry.yarnpkg.com/tar/-/tar-4.4.19.tgz#2e4d7263df26f2b914dee10c825ab132123742f3"
integrity "sha1-Lk1yY98m8rkU3uEMglqxMhI3QvM= sha512-a20gEsvHnWe0ygBY8JbxoM4w3SJdhc7ZAuxkLqh+nvNQN2IOt0B5lLgM490X5Hl8FF0dl0tOf2ewFYAlIFgzVA=="
```
Currently, yarn2nix isn't able to handle these lockfile entries,
producing an error like `error: hash 'Lk1yY98m8rkU3uEMglqxMhI3QvM=
sha512' has wrong length for hash type 'sha1'`. This is because it isn't
aware that spaces could separate multiple hashes.
This commit uses the official Standard Subresource Integrity package
from npm to parse the integrity line, and pick the best available
algorithm. It also replaced many of the local yarn2nix entries with
sha512, even ones that don't include it in the lockfile. Not sure how
that happened, but it works in practice!
The addition of `ssri` may also reduce signs and symptoms of depression.
The main usecase for this variable is to append --production to yarn
which now got a whole lot easier because you no longer need to repeat
the defaults.
This simplifies usages and makes the default value consistent.
In a few cases, the default value was interpreted to be `false`,
but this is useless, because virtually nobody will explicitly
set `allowAliases = true;`.
The `package.json` produced when building node_modules for a workspace
ignores the `resolutions` from the project `package.json`. This results
in dependencies being resolved in a way that conflicts with the
`yarn.lock` file. To fix this, we need to preserve the `resolutions`.
Move function spdxLicense, internally used in yarn2nix
to lib/meta.nix, and
rename to getLicenseFromSpdxId
A similar function is implemented in poetry2nix,
but the one originally in yarn2nix seems beter.
since it falls back to an license-like attrset
for mismatched case
instead of a plain string
Since b27d18a412 we fetch packages with codeload.github.com tarballs as
resolved field with fetchgit. The sha1 of the tarball is irrelevant,
instead nix-prefetch-git will be used to determine the expected fetchgit
FOD hash.
Fixes#143828
`pkgs.fetchgit` uses `fetchSubmodules = true;` by default, however
`nix-prefetch-git` doesn't. This means that hashes for a Git repository
with fetched submodules will be wrong in `yarn.nix`.
Considering that this got unnoticed before, it seems as if this case is
an exception to a certain degree.
An exemplary problem is the last `hedgedoc` update[1] where
`js-sequence-diagrams` - a Git repo with submodules - from upstream's
package.json caused a hash mismatch. This got unnoticed because
`nix-build --check` doesn't seem to reveal these issues for fixed-output
derivations.
[1] https://github.com/NixOS/nixpkgs/pull/139238
The way I see it, there's no point in the argument being there if it can't be used.
Right now its lack currently prevents a workaround for an issue I can't wrap my head around - first encountered [here](https://logs.nix.samueldr.com/nixos-dev/2019-08-28#2532857;).
@lheckemann already added it to `yarn2nix` a while ago[1], but it seems
as it was forgotten to include when adding `yarn2nix` sources to
`nixpkgs` itself.
Without this patch, you cannot add dependencies to your `package.json`
with URLs like `git://github.com/.../` as building the expression would
fail like this:
```
curl: (1) Protocol "git" not supported or disabled in libcurl
error: cannot download git___github.com_sstur_nodeftpd.git from any mirror
```
Co-authored-by: Linus Heckemann <git@sphalerite.org>
[1] https://github.com/nix-community/yarn2nix/pull/141
The generated yarnNix file doesn't need to be part of the mkDerivation.
And doing so prevents other platforms from reproducibly instantiating
it. With this change you can e.g. do
darwinPkgs.yarn2nix.mkYarnPackage {
# ...
yarnNix = pkgs.yarn2nix.mkYarnNix {
yarnLock = ./yarn.lock;
};
}
Which is a darwin derivation, but can still be instantiated reproducibly on Linux.
