| 23 Sep 2025 |
 mmkaram | In reply to @tomodachi94:matrix.org
In case you missed it on GitHub: this is queued to be merged. It will start trickling into channels soon (https://nixpk.gs is helpful for tracking that progression) Oh yeah I use that tracker all the time. Thanks for the merge! | 13:24:22 |
|  @acidbong:envs.net joined the room. | 14:59:39 |
| @acidbong:envs.net | evening, fellers and felines
related to Albert's package: his current effort looks like this, and i'm trying to replace the NPM archive with the Github source and run npm run build in it (diff), but tsc fails with this kinda error: https://termbin.com/9t7d
what could be the culprit? | 15:18:10 |
 Cobalt | In reply to @acidbong:envs.net
evening, fellers and felines
related to Albert's package: his current effort looks like this, and i'm trying to replace the NPM archive with the Github source and run npm run build in it (diff), but tsc fails with this kinda error: https://termbin.com/9t7d
what could be the culprit? This looks like not all deps were installed, specifically something for typescript. | 15:31:03 |
| Cobalt | In reply to @acidbong:envs.net
evening, fellers and felines
related to Albert's package: his current effort looks like this, and i'm trying to replace the NPM archive with the Github source and run npm run build in it (diff), but tsc fails with this kinda error: https://termbin.com/9t7d
what could be the culprit? * This looks like not all npm deps were installed, specifically something for typescript. | 15:31:23 |
| @acidbong:envs.net | anyway, is it still a good idea to use archives from NPM? i see some programs are packaged like that in Nixpkgs | 16:05:48 |
| Cobalt | It depends, ime building from upstream source is better as it is easier to debug issues from source inputs to compiled outputs.
Archives from npm often contain already compiled archives, which can be an easy way to sidestep a complex compile/build step.(similar to packaging upstream binaries).
| 18:06:17 |
 Albert Larsan | The issue is that for some reason, the package can only be built by running npm install && npm run bootstrap from the root of the repo. If I change a setting that makes it generate a lockfile for each package, then it breaks (because some stuff is not shared anymore) | 18:06:20 |
| Albert Larsan | Each package gets its own node_modules, but only one lockfile is generated (sometimes) | 18:08:04 |
| Albert Larsan | The issue you face is that some of the "internal" dependencies (ie in the same repo) are using types (in the dev-deps), but the main package does not include them in the repo's package.json (only in NPM's package.json) | 18:14:20 |
| Albert Larsan | One thing to try is to use NPM's package.json, but the repo's sources (then it may work) | 18:16:08 |
| 26 Sep 2025 |
| @acidbong:envs.net left the room. | 03:21:33 |
| 29 Sep 2025 |
 Emma [it/its] | Q: is there a way to make buildNpmPackage split up dependency fetches into separate drvs? | 23:42:45 |
| Emma [it/its] | i guess that'd add evaluator overhead, but would help a lot with all the redownloading when iterating over builds with minor package set changes | 23:43:59 |
| Emma [it/its] | in related news: any idea why, when i build my package with nix, it fails to start saying it's missing a module? | 23:45:33 |
| 30 Sep 2025 |
 dish [Fox/It/She] | nope | 00:04:52 |
| Emma [it/its] | ouch | 00:05:36 |
| dish [Fox/It/She] | thats a feature of some other builders but atm buildNpmPackage doesn't have that | 00:09:36 |
| dish [Fox/It/She] | iirc the yarn fetcher does though | 00:09:42 |
 Charles | my understanding is that builders in nixpkgs don't really care about granularity like this because in nixpkgs' case it often would need to rebuild everything anyway | 00:13:57 |
| Charles | * my understanding is that builders in nixpkgs don't really care about granularity like this in general because in nixpkgs' case it often would need to rebuild everything anyway | 00:14:06 |
| dish [Fox/It/She] | there's that yes | 00:15:22 |
| dish [Fox/It/She] | ideally with CA derivations we could just download the package once and be done with it | 00:15:37 |
| dish [Fox/It/She] | but CA derivations are far-term to never at this point so | 00:15:48 |
| dish [Fox/It/She] | with CA derivations that kind of granularity would actually be a good idea to have, since they could more easily be de-duplicated and re-used even if npm/node versions changed | 00:16:37 |
| dish [Fox/It/She] | * with CA derivations that kind of granularity would actually be a good thing to have, since they could more easily be de-duplicated and re-used even if npm/node versions changed | 00:16:42 |
| Emma [it/its] | well, youre building a local cache for it to use anyways, no?
i'd assume the tarballs wouldnt change? | 00:18:25 |
| Emma [it/its] | hm, is there some way to override dependencies with buildNpmPackage? | 00:19:34 |
| Emma [it/its] | say ie. i want to add a feature flag to my nix package for email support, or postgres support | 00:19:48 |
 Winter | what do you mean override? it sounds you’re specifically meaning it in the sense of adding or removing dependencies? | 01:02:25 |
