Nix NodeJS | 215 Members | |
| 63 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Jun 2026 | ||
| I'm experimenting with adding a nix package to nexus mods' Vortex repo: https://github.com/MattSturgeon/Vortex/tree/nix-package It uses pnpm, but my current package is failing with:
which almost seems like | 15:27:38 | |
| An ugly way to find out what that flag is being passed to is to add
| 18:43:52 | |
| Also make sure to use fetcherVersion = 4, as version 3 is not reproducible across different systems with pnpm 11 | 19:10:28 | |
| This is what I got
I assume the random empty string is the culprit | 19:11:07 | |
Yup. Removing the pnpmInstallFlags attribute fixes it | 19:12:05 | |
Another opportunity for me to mention my importPnpmLock.nix library (GitHub mirror) It's similar to importCargoLock, importNpmLock and others from Nixpkgs, though this one sadly only works using IFD, as your I have been using it at my workplace to build and package our Node apps using Nix. Without it, I wouldn't really be able to use Renovate bot very comfortably | 19:16:56 | |
| Ah, I'll probably need to bump nixpkgs too then; they have a nixpkgs pinned that says "unrecognized version, use 1, 2, or 3". Also, the Nixpkgs manual is still saying "version 3 is recommended for new packages", does that need updating? | 19:40:21 | |
Ah, enabling structuredAttrs seems to resolve that too; looks like empty flags list -> empty shell string with non-structured-attrs is buggy. Probably need to use stdenv's concatTo helper to normalize the flags array in the hook. | 19:45:18 | |
| The configure phase seems to be working now (pushed), thanks for the help! Now, two of build steps are failing. One of them ( https://github.com/Nexus-Mods/Vortex/blob/master/src/main/download-duckdb-extensions.ts The other one (
https://github.com/Nexus-Mods/Vortex/blob/master/extensions/theme-switcher/build.mjs | 20:48:53 | |
| 11 Jun 2026 | ||
| * The configure phase seems to be working now (pushed), thanks for the help! Now, two of build steps are failing. One of them ( https://github.com/Nexus-Mods/Vortex/blob/master/src/main/download-duckdb-extensions.ts EDIT: The first one I've worked-around with a fixed-output-derivation, but really needs upstream refactoring to improve how they fetch duckdb-extensions. The second one needed node-gyp to build a transitive dependency, oddly, I needed to run node-gyp manually in
https://github.com/Nexus-Mods/Vortex/blob/master/extensions/theme-switcher/build.mjs | 04:02:04 | |
| * The configure phase seems to be working now (pushed), thanks for the help! Now, two of build steps are failing. One of them ( https://github.com/Nexus-Mods/Vortex/blob/master/src/main/download-duckdb-extensions.ts EDIT: The first one I've worked-around with a fixed-output-derivation, but really needs upstream refactoring to improve how they fetch duckdb-extensions. The second one needed node-gyp to build a transitive dependency, oddly, I needed to run node-gyp manually in
https://github.com/Nexus-Mods/Vortex/blob/master/extensions/theme-switcher/build.mjs EDIT: The first one I've worked-around with a fixed-output-derivation, but really needs upstream refactoring to improve how they fetch duckdb-extensions. The second one needed node-gyp to build a transitive dependency, oddly, I needed to run node-gyp manually in | 04:02:28 | |
| Can also update the hook such that if fetcherVersion > 3, structuredAttrs is required 😎 | 15:23:52 | |
| 13 Jun 2026 | ||
| 03:22:58 | ||
| 16 Jun 2026 | ||
| I am working on an alternative pnpm fetcher here: https://github.com/NixOS/nixpkgs/pull/531657 It uses mitm-cache instead of creating a snapshot of the pnpm store. While there may be edge cases, from my experience with importPpnmLock.nix, it is quite robust, as pnpm only fetches tarballs in frozen lockfile mode. This may avoid the tedious fixup work we had to implement for fetchPnpmDeps and pnpmConfigHook | 11:15:49 | |
| Very cool! I personally think mitmCache is underutilized in Nixpkgs, so it's nice to see someone using it! | 13:40:30 | |
One issue I was running into with the Vortex package, is they pin some git+https://...#commit URLs (e.g.). Later during their build when they do a pnpm deploy, pnpm tries to re-resolve them (even with --frozen-lockfile or --offline), and fails attempting network requests. Would the new approach handle that better? | 18:07:32 | |
| At the moment it's only fetching tarballs as specified in the lockfile. There must be a way to prevent it from looking up Git sources though :O | 18:36:13 | |
| I know the yarn fetcher/hooks have some hacks for re-writing git-source lockfile entries, idk if the same principle applies to pnpm | 18:40:26 | |
| https://github.com/NixOS/nixpkgs/pull/489040 | 18:55:04 | |
| * I think I'm thinking of https://github.com/NixOS/nixpkgs/pull/489040 | 18:55:16 | |
| 21 Jun 2026 | ||
| 01:02:37 | ||
| 5 Dec 2022 | ||
| 14:44:17 | ||
| Thanks | 14:44:25 | |
In reply to @hexa:lossy.networkit doesn't look like he read the message, are you sure it wasn't just your server syncing the history :P | 14:45:19 | |
| ? | 14:45:48 | |
| 14:46:07 | |
| only future history | 14:46:16 | |
*
| 14:46:21 | |
| Yeah doesnt work into the past | 14:46:34 | |
Download IMG_20221205_154711.jpg | 14:47:23 | |