There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
This was supposed to go through a pull request
Revert "nodePackages: Regenerate node packages for nodejs 10 & 12"
This reverts commit 6a17bdf397.
Revert "nodejs-8_x: Drop package"
This reverts commit e06c97b71d.
It seems as NPM just removed the tarballs of the unpublished package,
hence `codimd` isn't buildable. The sources for the package are
available on github[1] and fix the build.
For further information about the `js-sequence-diagrams` workarounds,
please refer to 5feec424de.
[1] https://github.com/Moeditor/js-sequence-diagrams
This diff regenerates the package sets for `codimd` and `codemirror`
using NodeJS 8 to get rid of the deprecated[1] `nodejs-6_x`.
Additionally the following issues had to be fixed during the update:
* The package `js-sequence-diagram` has been removed from the NPM
registry and was replaced by a security holding package[2]. The
package was published by a third-party (upstream only supports bower
builds), so it's unclear whether the package will re-appear[3].
As the tarballs still exist (and the hash didn't change), the package
will be loaded manually into the build env.
* For the babel-related packages, `dontNpmInstall` will be set for
`node2nix` installs as some of those packages bundle a
`package-lock.json` that triggers `ENOTCACHED` errors for optional
dependencies[4].
For now it should be sufficient to use NodeJS 8 (`codimd` v1.2.x doesn't
support NodeJS 10), in the long term we probably want to use `yarn2nix`
here with NodeJS 10. This is much rather a fix to get rid of another
NodeJS 6 dependency.
[1] `nodejs-6_x` is about to be deprecated, see #58976
[2] https://www.npmjs.com/package/js-sequence-diagrams,
https://github.com/npm/security-holder
[3] https://github.com/bramp/js-sequence-diagrams/issues/212
[4] https://github.com/svanderburg/node2nix/issues/134
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
