This package broke during the update of `nodejs-10_x` to `v10.17.0`[1]
since `node-gyp` got updated from `3.8.0` to `5.0.3` during the NPM
update to `6.10.2`[2] which is bundled in the `nodejs` release tarball.
This `node-gyp`-version is used by the build script for `codimd` to
build several dependencies such as `node-sqlite3`. Older `node-gyp`
versions expected source headers for the compilation in `~/.node-gyp`,
with `node-gyp@5.0.3`, headers are declared by using the `--nodedir`
option.
[1] 7785f49b23
[2] e2291cf805
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.
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.
