Hey! Thank you for the PR! First let me thank you for your work on buildNpmPackage, it looks amazing and quite handy.

But at the risk of being a joy killer, is this what we want for jellyfin-web? I think buildNpmPackage is amazing for rapid packaging, and in the case where node2nix isn't feasible. The reason I think that we still want to use node2nix is for transparency / auditability: doing nix path-info -r --derivation on jellyfin-web with node2nix does tell you which NPM packages are used, and you can automatically audit if some of them have CVEs (with vulnix for example). Having a FOD makes us lose that property, unfortunately.

I do love the amount of deletion, but since a lot of lines are generated code, I wouldn't consider them a maintenance burden or technical debt. The web.nix and web-update.sh files seem quite simple to me.

What are you thoughts on this?

On a lighter note, just the fact that you managed to package the jellyfin-web that quickly is a feat in my opinion, congrats!

@tjni Do you mind moving your comments over to #200470 (which is where these changes are from), so I can reply in context? Thanks!

@minijackson That's definitely a valid concern. However, at the same time, I don't see what makes jellyfin-web different from any other npm package that will be converted in the future. Maybe we should wait on others to weigh in?

@winterqt yes, sorry for the confusion, I wasn't talking about jellyfin-web specifically. My point of view would be more like "for nixpkgs, try node2nix. If it doesn't work for you switch to buildNpmPackage"

for nixpkgs, try node2nix. If it doesn't work for you switch to buildNpmPackage

I disagree for a few reasons, mainly that the current package set (node-packages.nix):

• takes hours to generate
• updates affect other packages
• is very large

Isn't the package set for jellyfin self-contained in its own node-deps.nix? Or are there some dependencies pulled from the global node-packages.nix as well? I'm not very familiar with the Node ecosystem of nixpkgs.

You're correct, but you said that you weren't talking about jellyfin-web specifically.

I was talking about packages inside nixpkgs. I think all of them can have their own node-deps.nix, and we could forgo the global node-packages.nix? (This is complete speculation)

Yes, but we really don't want to have so many large generated files if we can help it.

I was talking about packages inside nixpkgs. I think all of them can have their own node-deps.nix, and we could forgo the global node-packages.nix? (This is complete speculation)

Some people are annoyed and find problematic that nixpkgs is holding so much data due to lockfiles appearing from everywhere in the repository, I am sympathetic to the issue, even if I am not really affected as I have plenty of disk space and fiber-speed bandwidth more or less everywhere.

Maybe, there should be a discussion on (a) what is the objective of lockfile reduction in nixpkgs? (b) how to balance this out with our objective of observability/SBOMs/supply chain security/transparency/auditability/etc. ?

Maybe, there should be a discussion on (a) what is the objective of lockfile reduction in nixpkgs? (b) how to balance this out with our objective of observability/SBOMs/supply chain security/transparency/auditability/etc. ?

Odd idea for (b): how about dumping a list of dependencies in a separate output?

Maybe, there should be a discussion on (a) what is the objective of lockfile reduction in nixpkgs? (b) how to balance this out with our objective of observability/SBOMs/supply chain security/transparency/auditability/etc. ?

Odd idea for (b): how about dumping a list of dependencies in a separate output?

It would be an idea, involving @nikstur as he has been working on https://github.com/nikstur/bombon for which this can be of interest.

Also, there was the idea of having a passthru.ssc.cycloneDX thing going in the NixOS SLSA matrix channel.

I think this is very much outdated by now? jellyfin-web seems to use buildNpmPackage.