| 19 Oct 2025 |
 Cobalt | A minor question/inquiry about importNpmLock, when a dependency for <foo> is specified as "<name>": "https://example.com/some.tar.gz", then importNpmLock will resolve & fetch it successfully as a dependency with the packages BUT will keep it as https:// within the packages.<foo>.depdendencies.<name> as https://example.com/some.tar.gz.
Regardless of integrity or metadata tags at least in my tests this means it will try to use the cacache-based cache for the downloaded file instead of the resolved file in packages."https://example.com/some.tar.gz". This will however fail as the cache lookup will fail (as there's no downloaded artifact in the cache) and subsequently it will exit early (when being required to fetch the tar from the address).
| 06:46:41 |
| Cobalt | Are dependencies like this not supported or is my understanding of this issue incomplete? | 06:47:25 |
| Cobalt | Background: lexical.dev is, among other methods, distributed via a tar from GitHub releases as @lexical/monorepo. And one of our projects workspace members has a dependency on it with "@lexical/monorepo": "https://github.com/facebook/lexical/archive/refs/tags/v0.20.2.tar.gz". | 06:49:41 |
| Cobalt | * A minor question/inquiry about importNpmLock, when a dependency for <foo> is specified as "<name>": "https://example.com/some.tar.gz", then importNpmLock will resolve & fetch it successfully as a dependency with the packages BUT will keep it as https:// within the packages.<foo>.depdendencies.<name> as https://example.com/some.tar.gz.
Regardless of integrity or metadata tags at least in my tests this means it will try to use the cacache-based cache for the downloaded file instead of the resolved file in packages."https://example.com/some.tar.gz". This will however fail as the cache lookup will fail (as there's no downloaded artifact in the cache) and subsequently it will exit early (when being required to fetch the tar from the address).
| 06:53:57 |
| Cobalt | * A minor question/inquiry about importNpmLock, when a dependency for <foo> is specified as "<name>": "https://example.com/some.tar.gz", then importNpmLock will resolve & fetch it successfully as a dependency with the packages BUT will keep it as https:// within the packages.<foo>.depdendencies.<name> as https://example.com/some.tar.gz.
Regardless of integrity or metadata tags at least in my tests this means it will try to use the cacache-based cache for the downloaded file instead of the resolved file in packages."https://example.com/some.tar.gz". This will however fail because the cache lookup fails (as there's no downloaded artifact in the cache) and subsequently it will exit early (when being required to fetch the tar from the address).
| 06:54:22 |
| 2 Nov 2025 |
 dish [Fox/It/She] | @Tomodachi94 (they/them) can I request reviews from you on nodePackages removal PRs? | 22:44:40 |
| dish [Fox/It/She] | since i know you've helped me with them in the past, just trying to get some fairly large ones moved that I've already personally reviewed | 22:45:06 |
| 4 Nov 2025 |
|  cafkafk changed their profile picture. | 08:23:10 |
| dish [Fox/It/She] | nodePackages' node-packages.nix file is now under 2mb! That means that it also now displays in the github webui | 18:31:56 |
| dish [Fox/It/She] | but the important thing is that the file is being deleted slowly | 18:32:04 |
| dish [Fox/It/She] | and it'll be 1.8mib once #457963 is merged | 18:34:01 |
| dish [Fox/It/She] | * nodePackages' node-packages.nix file is now under 2mib! That means that it also now displays in the github webui | 18:34:06 |
|  Lyn joined the room. | 20:36:17 |
| 5 Nov 2025 |
 Sandro 🐧 | Ui, that's really nice | 17:19:12 |
| Sandro 🐧 | Love it | 17:19:14 |
| dish [Fox/It/She] | now 1.73 mib with several more PRs merged | 17:36:06 |
| dish [Fox/It/She] | also under 50k lines which is a cool milestone | 17:36:19 |
| dish [Fox/It/She] | also, once all of my in-flight PRs removing stuff from nodePackages are merged, I'm going to do a single update to the package set to clean it up, and see what it removes. I don't want to do more than one update of it per release cycle, to keep churn down, but doing one allows us to clear out any unused deps that got missed along the way. | 18:20:07 |
| dish [Fox/It/She] | also, if anyone else does work moving packages out, please request reviews from me. I'm glad to do em | 18:22:21 |
| dish [Fox/It/She] | * also, if anyone else does work moving packages out, please request reviews from me, I'm glad to do em | 18:22:24 |
| 6 Nov 2025 |
|  @denbrahe:matrix.org left the room. | 15:30:07 |
| 9 Nov 2025 |
|  ghpzin (moved to @ghpzin:envs.net) changed their display name from ghpzin to ghpzin (moved to @ghpzin:envs.net). | 15:03:56 |
| 10 Nov 2025 |
| dish [Fox/It/She] | this has actually been something I've been thinking about recently lol. Take the existing code in pkgs/build-support/node/fetch-npm-deps and extend it to support more lockfile formats. That way we can potentially move away from our weird current fod fetchers(which frankly aren't too bad but they can be annoying sometimes since they rely on upstream keeping things consistant which... doesn't happen enough sadly >.>) | 02:46:15 |
| dish [Fox/It/She] | at the very least we may be able to reduce our dependence on anything outside of nixpkgs | 02:46:35 |
| dish [Fox/It/She] | also gives me a chance to remove the current (imo bad) yarn v1 tooling which relies on their out-of-date parser written in JS which just kinda sucks | 02:46:57 |
| dish [Fox/It/She] | * also it would me a chance to remove the current (imo bad) yarn v1 tooling which relies on their out-of-date parser written in JS which just kinda sucks | 02:47:05 |
| dish [Fox/It/She] | * also it would give me a chance to remove the current (imo bad) yarn v1 tooling which relies on their out-of-date parser written in JS which just kinda sucks | 02:47:07 |
| dish [Fox/It/She] | plus its written in rust which I like | 02:47:19 |
| dish [Fox/It/She] | * also it would give me a chance to remove the current (imo bad) yarn v1 tooling which relies on their out-of-date parser written in JS which just kinda sucks(note the tooling isn't bad i just dont like the reliance on yarn's really old and crusty parser) | 02:52:16 |
| 13 Nov 2025 |
|  @eveeifyeve:matrix.org left the room. | 07:22:51 |
