Up until now, the frontend was taken from `srcStatic`, i.e. prebuilt
from upstream. I recall at least three cases[1][2][3] where we got a hash
mismatch eventually.
Rather than spending time finding out whether or not it's a supply-chain
attack or just a build issue, I decided to implement a source-build now
with the following benefits:
* It's now actually possible to apply patches for Grafana's frontend.
* We rely a little less on third-party build systems.
Of course, patching potential vulnerabilities in transitive frontend
dependencies is still hard (let alone discovering that this package is
affected!), but that's a fundamental issue we have in nixpkgs and I
won't invent a half-baked solution just for this package, I still
consider this a step into the right direction.
The build itself mainly orients on the `yarn` commands used in the
upstream Makefile[4]. However, we can't use `fetchYarnDeps` here because
yarn v2 (a.k.a. `berry`) is in use which is why the same was done as in
`hedgedoc`, writing a custom FoD that downloads all dependencies and
writes the offline cache into `$out`[5].
Additionally there are two more notable differences to upstream:
* We patch out every dependency to `@grafana/e2e` and `cypress`. The
first is a dependency on the latter in another version and the latter
downloads random blobs from the Internet in postInstall. Since it's a
testing framework (and the `e2e` package apparently a testing
library), I decided it's not worth the effort and patched it out
everywhere.
* There was a `zoneinfo.zip` in `$out/share/grafana/tools` that was
installed from `srcStatic`. This only seems to be used on Windows[6]
and that's not supported by this package, so I decided to drop it.
[1] https://github.com/NixOS/nixpkgs/pull/251479
[2] https://github.com/NixOS/nixpkgs/pull/130201
[3] https://github.com/NixOS/nixpkgs/pull/104794
[4] https://github.com/grafana/grafana/blob/v10.3.1/Makefile
[5] https://github.com/NixOS/nixpkgs/pull/245170
[6] https://github.com/grafana/grafana/blob/v10.3.1/pkg/setting/setting.go#L1012-L1014