!NhAsaYbbgmzHtXTPQJ:funklause.de

Nix NodeJS

187 Members
55 Servers

Load older messages


SenderMessageTime
5 Nov 2025
@pyrox:pyrox.devdish [Fox/It/She]* also, if anyone else does work moving packages out, please request reviews from me, I'm glad to do em18:22:24
6 Nov 2025
@denbrahe:matrix.org@denbrahe:matrix.org left the room.15:30:07
9 Nov 2025
@9hp71n:matrix.orgghpzin (moved to @ghpzin:envs.net) changed their display name from ghpzin to ghpzin (moved to @ghpzin:envs.net).15:03:56
10 Nov 2025
@pyrox:pyrox.devdish [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
@pyrox:pyrox.devdish [Fox/It/She]at the very least we may be able to reduce our dependence on anything outside of nixpkgs02:46:35
@pyrox:pyrox.devdish [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 sucks02:46:57
@pyrox:pyrox.devdish [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 sucks02:47:05
@pyrox:pyrox.devdish [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 sucks02:47:07
@pyrox:pyrox.devdish [Fox/It/She]plus its written in rust which I like02:47:19
@pyrox:pyrox.devdish [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@eveeifyeve:matrix.org left the room.07:22:51
14 Nov 2025
@pyrox:pyrox.devdish [Fox/It/She]today in cursed JS stuff: angular-cli is built with bazel but still uses pnpm to manage JS dependencies02:31:22
@pyrox:pyrox.devdish [Fox/It/She]also its bazel version is too new for nixpkgs atm so we need to wait for 7.7.0 to get merged for it to build :)02:32:41
@tomodachi94:matrix.orgTomodachi94 (they/them)Sorry for the delay. Totally!15:04:36
@pyrox:pyrox.devdish [Fox/It/She]
In reply to @tomodachi94:matrix.org
Sorry for the delay. Totally!
all good! all of them have gone through now but if I ever have more in the future I'll let you know ^^
15:51:56
16 Nov 2025
@tomodachi94:matrix.orgTomodachi94 (they/them)Happy to review any sort of PR that reduces technical debt, broadly speaking04:59:45
17 Nov 2025
@stephen:crabsin.spacen3tcat changed their profile picture.01:20:56
@robert:funklause.dedotlambdaShould we update nodePackages once before branch-off?01:31:16
@pyrox:pyrox.devdish [Fox/It/She]maybe? I would rather keep it frozen since the set is deprecated but since I'm not doing any work on it for the time being then i have no merge conflict complaints if you do so02:31:45
@pyrox:pyrox.devdish [Fox/It/She]though if updating the set drops the LoC then I'd be in favor I suppose02:32:18
@robert:funklause.dedotlambda
In reply to @pyrox:pyrox.dev
though if updating the set drops the LoC then I'd be in favor I suppose
I assume it would
03:42:04
@tomodachi94:matrix.orgTomodachi94 (they/them)What's the best way to approach packaging a Node CLI project that doesn't have a lockfile? There's one in nodePackages that I would love to migrate over and start maintaining but I'm not sure what best-practice is03:42:28
@robert:funklause.dedotlambdaOne argument in favor is that we might inadvertently have some vulnerabilities in the current package set03:42:46
@robert:funklause.dedotlambda
In reply to @tomodachi94:matrix.org
What's the best way to approach packaging a Node CLI project that doesn't have a lockfile? There's one in nodePackages that I would love to migrate over and start maintaining but I'm not sure what best-practice is
Ask upstream to add a lock file
03:43:16
@robert:funklause.dedotlambdaIf we absolutely have to keep the package, I guess we have to vendor package-lock.json03:43:43
@tomodachi94:matrix.orgTomodachi94 (they/them) I'll ask upstream first. The package in question is awesome-lint 03:47:35
@pyrox:pyrox.devdish [Fox/It/She]sindresorhus hates lockfiles for some reason, good luck getting him to put one in any of his projects03:50:12
@pyrox:pyrox.devdish [Fox/It/She]wish he wouldnt cuz it would make a LOT of the nodePackages set disappear03:50:44
@pyrox:pyrox.devdish [Fox/It/She]* wish he did have lockfiles cuz it would make a LOT of the nodePackages set disappear03:50:58
@tomodachi94:matrix.orgTomodachi94 (they/them)He wrote a very famous thing about how lockfiles are for "apps, not CLIs"... which makes his stance very confusing03:53:14

Show newer messages


Back to Room ListRoom Version: 6