| 2 Mar 2026 |
 hexa | https://github.com/NixOS/nixpkgs/issues/489959 is complete | 23:27:15 |
| hexa | @dish [Fox/It/She] thanks for your persistence in this matter | 23:27:35 |
| 3 Mar 2026 |
|  debtquity joined the room. | 00:22:50 |
| debtquity | anybody with exp packaging next js apps able to help out here? https://discourse.nixos.org/t/buildnpmpackage-and-next-js/75814 | 00:25:53 |
|  @rosssmyth:matrix.org changed their display name from rosssmyth to treefroog. | 00:40:04 |
| @rosssmyth:matrix.org removed their display name treefroog. | 00:42:23 |
 dish [Fox/It/She] | In reply to @hexa:lossy.network
@dish [Fox/It/She] thanks for your persistence in this matter 🫡 im glad to help, this has been a thorn in my side for several months and im so glad to finally close it out | 04:08:01 |
| dish [Fox/It/She] | working on a set of PRs to delete it for good. | 22:08:15 |
| dish [Fox/It/She] | https://github.com/NixOS/nixpkgs/pull/496365 | 22:28:54 |
| dish [Fox/It/She] | 🙌 | 22:29:06 |
 emily | there's some node2nix mentions in the docs that probably need cleaning up fwiw | 22:38:51 |
| 5 Mar 2026 |
| debtquity | was able to pick up on this again, and able to move forward by splitting out the subpackages into their own npmBuildPackage modules. But now run this:
error: Cannot build '/nix/store/rz8xy8azk6rqljygb8xh0mx3hqnc19ci-internal-ui-1.52.2.drv'.
Reason: builder failed with exit code 1.
Output paths:
/nix/store/llw47jbqbvb8zdza926ikdrsca92y37h-internal-ui-1.52.2
Last 25 log lines:
>
> vite v6.3.5 building for production...
> ✓ 0 modules transformed.
> ✗ Build failed in 3ms
> error during build:
> [typescript] [plugin typescript] @rollup/plugin-typescript: Could not find module 'tslib', which is required by this plugin. Is it installed?
man, adapting the node ecoystem to nix is quite difficult
| 06:50:17 |
| 8 Mar 2026 |
|  Matan (ixxie) changed their display name from ixxie (Matan) to Matan (ixxie). | 10:43:11 |
|  SomeoneSerge (matrix works sometimes) changed their display name from SomeoneSerge (back on matrix) to SomeoneSerge (matrix works sometimes). | 23:31:05 |
| 9 Mar 2026 |
|  Scrumplex joined the room. | 20:51:03 |
| Scrumplex | I am currently working on importPnpmLock to support package builds without having a pnpmDeps FOD: https://tangled.org/scrumplex.net/importPnpmLock.nix
This is mostly useful for projects that use dependabot or renovate where keeping pnpmDeps up-to-date is cumbersome.
It is very bare bones, but should support everything pnpm has to offer due to its fundamental design:
Instead of trying to be smart about it, we just use the existing mitmcache infrastructure from nixpkgs. Luckily, the pnpm lock file contains everything* we need and the only issue is that it's a YAML file, leading to IFD in my implementation. While a pnpm2nix-style script would have avoided IFD, it would have the same issues as the status quo (updating hashes).
| 20:55:15 |
| Scrumplex | * I am currently working on importPnpmLock to support package builds without having a pnpmDeps FOD: https://tangled.org/scrumplex.net/importPnpmLock.nix
This is mostly useful for projects that use dependabot or renovate where keeping pnpmDeps up-to-date is cumbersome.
It is very bare bones, but should support everything pnpm has to offer due to its fundamental design:
Instead of trying to be smart about it, we just use the existing mitmcache infrastructure from nixpkgs. Luckily, the pnpm lock file contains everything* we need and the only issue is that it's a YAML file, leading to IFD in my implementation. While a pnpm2nix-style script would have avoided IFD, it would have the same issues as the status quo (updating hashes).
*: Git as well as tarball dependencies are not locked with the exact tarball hash. Those have to be specified manually, similar to how importCargoLock does it. | 20:55:55 |
| Scrumplex | * I am currently working on importPnpmLock to support package builds without having a pnpmDeps FOD: https://tangled.org/scrumplex.net/importPnpmLock.nix
This is mostly useful for projects that use dependabot or renovate where keeping pnpmDeps up-to-date is cumbersome.
It is very bare bones, but should support everything pnpm has to offer due to its fundamental design:
Instead of trying to be smart about it, we just use the existing mitmcache infrastructure from nixpkgs. Luckily, the pnpm lock file contains everything* we need and the only issue is that it's a YAML file, leading to IFD in my implementation. While a pnpm2nix-style script would have avoided IFD, it would have the same issues as the status quo (updating hashes).
*: Git as well as tarball dependencies are not locked with the exact tarball hash. Those have to be specified manually, similar to how importCargoLock does it. | 20:56:26 |
| Scrumplex | I took vencord from nixpkgs as an example package and swapped out the existing fetchPnpmDeps-based tooling for importPnpmLock: https://tangled.org/scrumplex.net/importPnpmLock.nix/blob/main/checks/vencord.nix
I also started to use this for some of my personal projects.
It may run into some edge cases and the interface isn't finalized, but it works great for being a PoC
| 20:57:58 |
| Scrumplex | * I am currently working on importPnpmLock to support package builds without having a pnpmDeps FOD: https://tangled.org/scrumplex.net/importPnpmLock.nix
This is mostly useful for projects that use dependabot or renovate where keeping pnpmDeps up-to-date is cumbersome.
It is very bare bones, but should support everything pnpm has to offer due to its fundamental design:
Instead of trying to be smart about it, we just use the existing mitmcache infrastructure from nixpkgs. Luckily, the pnpm lock file contains everything* we need and the only issue is that it's a YAML file, leading to IFD in my implementation. While a pnpm2nix-style script would have avoided IFD, it would have the same issues as the status quo (updating hashes).
*: Git as well as tarball dependencies are not locked with the exact tarball hash. Those have to be specified manually, similar to how importCargoLock does it. | 20:58:21 |
| @rosssmyth:matrix.org | Nice! I was looking into making an IFD pnpm lockfile import | 23:52:30 |
| 10 Mar 2026 |
|  amadaluzia joined the room. | 01:46:22 |
| 11 Mar 2026 |
|  srasu joined the room. | 01:48:34 |
| srasu | Hello! I'm trying out packaging out-of-your-element and I'm trying to figure out how to use buildNpmPackage to do so. It seems like doing that doesn't result in me being able to call the various scripts available via npm run <subcommand>, which is the primary way to interact with it. Is there a way to do that with buildNpmPackage? | 01:50:35 |
| hexa | none of the scripts looks like a build script | 02:00:15 |
| srasu | that's correct, there's no "build", it's just a collection of scripts meant to be run with npm run | 02:01:08 |
| srasu | The flow I'm looking for here more or less is to be able to do a nix run .#ooye-setup to call the npm run setup command, use it interactively to produce a file, then use requireFile to provide it to another derivation that will call npm run start | 02:01:28 |
| srasu | I don't know if that will be feasible | 02:01:54 |
| srasu | I think I figured it out for my case | 02:58:27 |
| srasu | I ended up needing to make my own installPhase that copied over the project to the $out and used makeWrapper to make scripts that call node to run the relevant scripts. | 02:59:00 |
