Idea shamelessly stolen from 4e60b0efae56cc8e1a8a606a5a89462c38aba305.
I realized that I don't really know anymore where I'm listed as maintainer and what
I'm actually (co)-maintaining which means that I can't proactively take
care of packages I officially maintain.
As I don't have the time, energy and motivation to take care of stuff I
was interested in 1 or 2 years ago (or packaged for someone else in the
past), I decided that I make this explicit by removing myself from several
packages and adding myself in some other stuff I'm now interested in.
I've seen it several times now that people remove themselves from a
package without removing the package if it's unmaintained after that
which is why I figured that it's fine in my case as the affected pkgs
are rather low-prio and were pretty easy to maintain.
This was supposed to go through a pull request
Revert "nodePackages: Regenerate node packages for nodejs 10 & 12"
This reverts commit 6a17bdf3974fce9d0c5098e77aa5fe6de279f2c7.
Revert "nodejs-8_x: Drop package"
This reverts commit e06c97b71d33bf8480fb40f825e8d3138783f986.
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.
Airfield suffered from loose version constraints which
caused severe version (and API) conflicts between its dependencies
and transitive ones.
Furthermore the `npm2nix` packaging is deprecated and needed to be
replaced by `node2nix`.
see #31032
