| 8 Feb 2024 |
 @adis:blad.is | Is there any rationale for keeeping buildNpmPackage around anymore?
Imo it should be dropped in favour of just using stdenv.mkDerivation | 01:26:21 |
 @kranzes:matrix.org | Explain | 03:12:07 |
| @kranzes:matrix.org | Is this because of npmHooks? | 03:12:36 |
| @kranzes:matrix.org | Or whatever that's called | 03:12:47 |
| @kranzes:matrix.org | I don't mind buildNpmPackage | 03:13:12 |
| @adis:blad.is | In reply to @kranzes:matrix.org
Is this because of npmHooks? This is because it's not really doing much, so it's a functional stdenv abstraction for not much gain | 04:11:08 |
| @adis:blad.is | Essentially it's just this:
stdenv.mkDerivation (args // {
inherit npmDeps npmBuildScript;
nativeBuildInputs = nativeBuildInputs
++ [ nodejs npmConfigHook npmBuildHook npmInstallHook nodejs.python ]
++ lib.optionals stdenv.isDarwin [ darwin.cctools ];
buildInputs = buildInputs ++ [ nodejs ];
strictDeps = true;
# Stripping takes way too long with the amount of files required by a typical Node.js project.
dontStrip = args.dontStrip or true;
meta = (args.meta or { }) // { platforms = args.meta.platforms or nodejs.meta.platforms; };
})
| 04:11:32 |
| @adis:blad.is | My take is: Just use the hooks | 04:12:49 |
| @adis:blad.is | stdenv.mkDerivation wrappers are an anti-pattern | 04:13:19 |
| @adis:blad.is | Using the hooks is more composable as well | 04:14:06 |
| @adis:blad.is | It makes it possible to for example build a Go application backend and the web frontend all in one derivation | 04:14:58 |
