Nix NodeJS - Public Room Timeline

	Nix NodeJS	193 Members
		57 Servers

Load older messages

Sender	Message	Time
29 Oct 2024
hexa	the nodejs stuff is entirely dev deps after all	13:19:01
hexa	they were telling me they build their css with sass and stuff	13:19:13
hexa	and then npm only contains linters	13:19:19
	@mat:matrix.matmoa.xyz left the room.	19:58:10
31 Oct 2024
	@arexon:matrix.org joined the room.	05:47:47
	pxc joined the room.	19:38:31
pxc	I've been trying to fix the build of `bitwarden-cli` on `aarch64-darwin`. It's built with `buildNpmPackage`. The issue is in one of the transitive dependencies which builds a C++ executable via `node-gyp`, and that fails during the `patchPhase`. I've been able to get builds of the same package (on a newer version) to build as part of Nixpkgs' `nodePackages` (though I'm not sure it's correct). What's the right way to tackle this from here? If I switch to building it via node2nix, can I override recursive dependencies as well as top-level ones?	19:54:46
pxc	* I've been trying to fix the build of `bitwarden-cli` on `aarch64-darwin`. It's built with `buildNpmPackage`. The issue is in one of the transitive dependencies which builds a C binary (in newer versions, it's C++) via `node-gyp`, and that fails during the `patchPhase`. I've been able to get builds of the same package (on a newer version) to build as part of Nixpkgs' `nodePackages` (though I'm not sure it's correct). What's the right way to tackle this from here? If I switch to building it via node2nix, can I override recursive dependencies as well as top-level ones?	19:55:21
pxc	Last night I started trying to move `bitwarden-cli` (back?) into `nodePackages`, but it doesn't seem right. I think I might have to also add `@microsoft/signalr`, which depends on this broken package with native deps (`utf-8-validate`) and add an override for it to point it at the fixed `utf-8-validate` package? But I'm not sure if I'm headed down the wrong path with that effort.	19:58:16
Lily Foster	In reply to @pxc:matrix.org I've been trying to fix the build of `bitwarden-cli` on `aarch64-darwin`. It's built with `buildNpmPackage`. The issue is in one of the transitive dependencies which builds a C++ executable via `node-gyp`, and that fails during the `patchPhase`. I've been able to get builds of the same package (on a newer version) to build as part of Nixpkgs' `nodePackages` (though I'm not sure it's correct). What's the right way to tackle this from here? If I switch to building it via node2nix, can I override recursive dependencies as well as top-level ones? can you share any more context about what's failing? you are probably just missing some dep the C++ plugin requires	19:58:43
pxc	* Last night I started trying to move `bitwarden-cli` (back?) into `nodePackages`, but it doesn't seem right. I think I might have to also add `@microsoft/signalr`, which depends on this broken package with native deps (`utf-8-validate`) and add an override for it to point it at the fixed `utf-8-validate` package? I'm just not sure if I'm headed down the wrong path with that effort.	19:58:46
pxc	* Last night I started trying to move `bitwarden-cli` (back?) into `nodePackages`, but it doesn't seem right. I think I might have to also add `@microsoft/signalr`, which depends on this broken package with native deps (`utf-8-validate`) and add an override for it to point it at the fixed `utf-8-validate` package? I'm just not sure if I'm headed down the right path with that effort.	19:58:59
Lily Foster	node2nix/nodePackages will only result in more pain and incorrectly packaged things for everyone. it's dead	19:59:11
pxc	it's a weird failure where it tries to create a fat binary with the aarch64 parts of the executable twice	19:59:26
Lily Foster	logs?	19:59:50
pxc	when I tried building `utf-8-validate` (the latest version) by itself, as part of `nodePackages`, it worked when I added `node-gyp` and `libtool`, but I think the deps needed by the older version pulled in by `@microsoft/signalr` might be different	20:00:35
pxc	sure thing, 1 sec	20:00:38
pxc	here's the build log: https://pastebin.com/2VP96FLp	20:02:31
pxc	here's an existing Nixpkgs issue that points to a piece of the breakage that was already solved (macOS needs `perl` in the `nativeBuildInputs` for `bitwarden-cli` since `utf-8-validate` uses `perl` one-liners in its gyp config: https://github.com/NixOS/nixpkgs/issues/339576	20:03:51
pxc	and I don't totally know what to make of them, but some of the conditional gyp bindings in different versions of that dep seem instructive somehow. In the latest version of `utf-8-validate`, `binding.gyp` looks like this: https://github.com/websockets/utf-8-validate/blob/master/binding.gyp	20:11:12
Lily Foster	In reply to @pxc:matrix.org here's the build log: https://pastebin.com/2VP96FLp it's building the x86_64 validator as aarch64...?	20:15:17
pxc	yeah	20:15:26
pxc	there are a small number of occurrences of this problem in other packages as well, unresolved	20:15:49
pxc	when I got the latest version of `utf-8-validate` to build by itself, adding `libtool` to the `buildInputs` made it stop doing this, it seems	20:16:10
Lily Foster	i can't even tell if the upstream dep is busted at 5.0.10 or if it's darwin sdk fuckery that might be fixed on master as of this morning	20:16:12
pxc	the conditions in `binding.gyp` seem more sophisticated in that latest version than in some others that appear in the tree	20:16:48
pxc	`utf-8-validate` is a dependency of `@wessberg/ts-evaluator` as well but I don't see it in my `node_modules` when debugging with `nix-shell`	20:17:23
emily	doesn't look particularly SDK-refactor-related but I strongly encourage rebasing on current `master` all the same	20:17:27
pxc	* `utf-8-validate` is a dependency of `@wessberg/ts-evaluator` as well but I don't see it in my `node_modules` when debugging with `nix-shell`/`nix develop`	20:17:29
Lily Foster	In reply to @pxc:matrix.org the conditions in `binding.gyp` seem more sophisticated in that latest version than in some others that appear in the tree sophistication isn't what changed. it's that they stopped building "fat" binaries with both x86_64 and aarch64 object code in them at the same time	20:17:51

Show newer messages

Back to Room ListRoom Version: 6