| 11 Oct 2025 |
 dish [Fox/It/She] | and they have changed their lockfile schema a lot so you would need a lot of intermediate versions to bootstrap from somewhere with no lockfile | 03:27:36 |
| dish [Fox/It/She] | the last version with no lockfile is v0.64.2 from 2017, and the next release(0.64.3) uses a shrinkwrap.yaml file, which is the precursor to pnpm-lock.yaml | 03:28:46 |
| dish [Fox/It/She] | the best way to do this would be a package-lock.json and a patch to make the minimal critical build steps use npm instead of pnpm cli | 03:29:23 |
| dish [Fox/It/She] | but thats a very involved patch and its really sad that they dont allow for this | 03:29:33 |
 Cobalt | That is worse than expected, thank you for the explainer | 03:35:47 |
| Cobalt | An alternative approach might be to write a translator between lockfile formats. But that's also quite a bit of extra work | 03:44:36 |
 magic_rb | Leave it to the JS people to make bootstrap impossible. JS folk seem to be living a fantasy land where nothing but npx matters and everything can be resolved with just one more package manager and web framework | 06:19:45 |
| magic_rb | * | 06:20:07 |
| dish [Fox/It/She] | yeag | 06:33:27 |
| dish [Fox/It/She] | i've been researching with a friend and just | 06:33:46 |
| dish [Fox/It/She] | gods it gives me a headache | 06:33:52 |
 Marie | same thing applies to bun last time i looked at it | 09:50:22 |
| Marie | :/ | 09:50:24 |
| 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 |
