| 7 Oct 2025 |
 Emma [it/its] | nvm, npmBuildScript lol | 13:47:33 |
| 9 Oct 2025 |
|  @eveeifyeve:matrix.org joined the room. | 02:58:25 |
| @eveeifyeve:matrix.org | CC Winter & Lily Foster: https://github.com/NixOS/nixpkgs/issues/317927#issuecomment-3383799636 | 02:58:55 |
 Winter | you don’t have to ping us here too, i assure you we read GitHub notifs | 03:00:16 |
| @eveeifyeve:matrix.org | I only did it because tomberek advised me in the unofficial nix discord to do so. | 07:40:50 |
| @eveeifyeve:matrix.org | * I only did it because tomberek advised me in the unofficial nix discord to do so. Incase you miss your notfications. | 07:41:22 |
| @eveeifyeve:matrix.org | * I only did it because tomberek advised me in the unofficial nix discord to do so. In case you miss your notifications. | 07:41:36 |
| 11 Oct 2025 |
 dish [Fox/It/She] | https://github.com/orgs/pnpm/discussions/8602 😔 | 03:13:29 |
| dish [Fox/It/She] | the js ecosystem makes me so sad | 03:15:50 |
 Cobalt | Well, someone motivated could figure out how to bootstrap it from earlier versions.
My guess is that a chain of at most three will work. Don't GCC and friends also need that? It's a bit overkill for a package manager though | 03:22:28 |
| Cobalt | * | 03:23:55 |
| dish [Fox/It/She] | every version with a lockfile has used pnpm lockfiles | 03:27:13 |
| 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 |
