!NhAsaYbbgmzHtXTPQJ:funklause.de

Nix NodeJS

209 Members
61 Servers

You have reached the beginning of time (for this room).

SenderMessageTime
17 Jan 2024
@janne.hess:helsinki-systems.deJanne Heß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 it09:46:35
@c0ba1t:matrix.orgCobaltMy best guess would be that it just hasn't been implemented (yet).12:37:14
@c0ba1t:matrix.orgCobalt Lily Foster: iirc, mentioned working on something similar. 12:37:52
@lily:lily.flowersLily Foster yep, Cobalt is correct 13:06:17
@lily:lily.flowersLily Fosteri'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 lockfiles13:07:13
@lily:lily.flowersLily Foster (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
@kstiehl:matrix.numericas.de@kstiehl:matrix.numericas.de
In reply to @lily:lily.flowers
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
Lily 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
@h7x4:nani.wtfh7x4

Hello. I'm having some trouble with the lockfile fixup stage of npm-config-hook

One of the dependencies are listed as git+https://git.sr.ht/~cadence/nodejs-discord-markdown#abc56d544072a1dc5624adfea455b0e902adf7b3, which successfully gets rewritten to https://git.sr.ht/~cadence/nodejs-discord-markdown/archive/abc56d544072a1dc5624adfea455b0e902adf7b3.tar.gz during the cache creation stage, and written to package.metadata.url. But during the lockfile fixup it can't retrieve the hash, seemingly because it tries to match up the first untouched URL with the second rewritten one.

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
@dandellion:dodsorf.asDandellionFor 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.dev19:19:12
@lily:lily.flowersLily Foster
In reply to @kstiehl:matrix.numericas.de
Lily 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😅
i've not had time, sorry :( 		23:15:48
@lily:lily.flowersLily Foster
In reply to @h7x4:nani.wtf

Hello. I'm having some trouble with the lockfile fixup stage of npm-config-hook

One of the dependencies are listed as git+https://git.sr.ht/~cadence/nodejs-discord-markdown#abc56d544072a1dc5624adfea455b0e902adf7b3, which successfully gets rewritten to https://git.sr.ht/~cadence/nodejs-discord-markdown/archive/abc56d544072a1dc5624adfea455b0e902adf7b3.tar.gz during the cache creation stage, and written to package.metadata.url. But during the lockfile fixup it can't retrieve the hash, seemingly because it tries to match up the first untouched URL with the second rewritten one.

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?

it's a bug. i've found it and am about to submit a PR in a few 		23:19:03
@lily:lily.flowersLily Fostererr wait, no maybe i haven't found the bug. that didn't work. give me a few23:20:45

Show newer messages

Back to Room ListRoom Version: 6