Nix NodeJS | 204 Members | |
| 59 Servers |
| Sender | Message | Time |
|---|---|---|
| 15 Jan 2024 | ||
| can you share the derivation? | 14:52:23 | |
| https://github.com/NixOS/nixpkgs/blob/23.11/pkgs/development/tools/continuous-integration/woodpecker/frontend.nix I am trying to update the woodpecker package. And it fails in the frontend derivation. | 14:57:46 | |
| ah, can you share your updated derivation too? i'll try to look sometime today if no one else is able to help before i'm at my computer again | 14:58:23 | |
| gimme a sec I'll create a fork of the repo real quick with my changes included | 14:59:50 | |
| https://github.com/kstiehl/nixpkgs/blob/update/woodpecker/pkgs/development/tools/continuous-integration/woodpecker/frontend.nix Lily Foster Sorry took a bit longer. I made sure that it is actually reproducible, and during that my VM run out of disk space. However Here it is :) | 15:48:46 | |
| 17 Jan 2024 | ||
| Is there a reason we don't have a way of specifying the package-lock.json without a hash? We can do this with cargo as well and to me it looks like we can fromJSON the package lock and get the URLs and SRI hashes from it | 09:46:35 | |
| My best guess would be that it just hasn't been implemented (yet). | 12:37:14 | |
| Lily Foster: iirc, mentioned working on something similar. | 12:37:52 | |
| yep, Cobalt is correct | 13:06:17 | |
| i'm working on lockfile fixup refactoring because lockfiles are, uh, a bit too busted a bit too often and also we need to inject git dep hashes anyway so it'll be able to do overrides to solve the problem of busted lockfiles without having to regenerate and vendor lockfiles | 13:07:13 | |
(my use-case is still mostly nixpkgs-focused here, but it will greatly benefit out-of-tree modules with the importNpmLock functionality) | 13:07:50 | |
In reply to @lily:lily.flowersLily Foster: hi did you find the time to have a look? If not that's fine too. Just want to know whether i should keep my hopes up😅 | 16:28:07 | |
| Hello. I'm having some trouble with the lockfile fixup stage of One of the dependencies are listed as Since we're doing this kind of rewriting for all kinds of URLs, I'm wondering whether I've misunderstood something? Is there some kind of mechanism in place for the other URLs to ensure we're able to look them up from the cache after rewriting their URLs? | 19:08:56 | |
| For added context this is the same package as we previously talked about in https://matrix.to/#/!NhAsaYbbgmzHtXTPQJ:funklause.de/$dTuHZBRPJkPGn0WSjuBWwhnp1IiEt9yqDbkCA7uXXpU?via=nixos.org&via=matrix.org&via=nixos.dev | 19:19:12 | |
In reply to @kstiehl:matrix.numericas.dei've not had time, sorry :( | 23:15:48 | |
In reply to @h7x4:nani.wtfit's a bug. i've found it and am about to submit a PR in a few | 23:19:03 | |
| err wait, no maybe i haven't found the bug. that didn't work. give me a few | 23:20:45 | |
| No worries 😄 Ping me if you'd like the package file with the current failing setup. | 23:23:45 | |
In reply to @h7x4:nani.wtfsure, i made my own super quickly but that would probably help too | 23:25:48 | |
| i'm starting to wonder if this is just an npm bug? at least in my reproducer, it has nothing to do with lockfile fixup afaict | 23:30:04 | |
| npm says "tarball data seems to be corrupted" even though hash matches and the tarball seems valid 🤔 | 23:30:38 | |
| I've bundled a patch, likely introducing IFD, but good enough for testing.
| 23:34:11 | |
| gods i wish npm's debug logging wasn't so slim and convenient not say where or why the error actually happened... | 23:57:46 | |
| * gods i wish npm's debug logging wasn't so slim and not say where or why the error actually happened... | 23:57:55 | |
| 18 Jan 2024 | ||
| 04:14:31 | ||
| 19 Jan 2024 | ||
| 05:12:19 | ||
| 05:14:42 | ||
| 22 Jan 2024 | ||
| What is the right way to not copy node_modules into lib folder with buildNpmPackage? As it's a static frontend code it doesn't need that folder at all | 09:37:28 | |
Ah, I guess I should have just added dontInstall = true 😅 | 09:51:24 | |
| you could also set installPhase for copying the build output to $out | 10:36:20 | |