[WIP] deno.fetchDeps: init

[pluiedev]

This PR is like #326003, but considerably more minimal and based on Deno 2.0.

I believe the other PR is doing way too much than what is strictly necessary at this point, and a more composable design with hooks and dependency fetchers is more in line with what Nixpkgs is gravitating towards with tools like cargo-tauri and pnpm.

Note that the closure size with Deno deps might be considerably bigger than the same dependencies fetched with either fetchNpmDeps and pnpm.fetchDeps, due to the lack of a content-addressible mechanism. fetchNpmDeps has its own code that generates a content-addressible closure but I'm a) not exactly sure how it works and b) how it is restored to a normal node_modules structure, and pnpm is designed around CA stores as a core design. Still, this is possibly a future problem to solve.

Marking as draft for now as there's some more polishing that can be done for the scripts, and maybe a build/install hook should be added like the other PR.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[winterqt]

This will break the FODs almost instantly if Deno changes anything in how they pull deps, and also is probably not reproducible between platforms when platform-specific dependencies are used.

Does Deno have a flag that can mitigate at least the second issue?

[pluiedev]

This will break the FODs almost instantly if Deno changes anything in how they pull deps, and also is probably not reproducible between platforms when platform-specific dependencies are used.

Does Deno have a flag that can mitigate at least the second issue?

I at least have tested this on aarch64-linux and x86_64-linux, and it seems to work just fine. As for the former issue, I believe we could do what pnpm did and just pin Deno versions

[Scrumplex]

I'd suggest opening an issue upstream and establish some reproducibility guarantees (if upstream is willing)

[pluiedev]

I'd suggest opening an issue upstream and establish some reproducibility guarantees (if upstream is willing)

The author of the previous PR has already made upstream incorporate a number of reproducibility guarantees. Now I'm just testing whether it is completely reliable just yet

[pluiedev]

I've been experimenting with how the API should look like for an application that uses Deno, and this is what I've come up with for now:

{
  lib,
  stdenv,
  fetchFromGitHub,
  deno,
  jq,
}:
stdenv.mkDerivation (finalAttrs: {
  pname = "studio-pack-generator";
  version = "0.5.12";

  src = fetchFromGitHub {
    owner = "jersou";
    repo = "studio-pack-generator";
    rev = "v0.5.12";
    hash = "sha256-pfrF/jydpLF5o3aacQ33o5/kUcXooXTb3+ggX7+u+3s=";
  };

  nativeBuildInputs = [ 
    jq 
    deno.setupHook 
    deno.compileHook 
  ];
  
  denoEntrypoints = [ "studio_pack_generator.ts" ];

  denoDeps = deno.fetchDeps {
    inherit (finalAttrs) pname src denoEntrypoints;
    hash = "sha256-UFR3oiJspzRYQni4o5yhi00kufpckTmWdAilR62e+xk=";
  };

  denoCompileFlags = [
    "--allow-all"
    "--unstable"
  ];
})

A couple of design notes:

• No buildDenoApplication of any sort since Deno can be used in a lot of different contexts, including as a task runner, a package manager, or a fully fledged flamework for an application. A modular approach would be better here.

• deno.setupHook would prepare the Deno cache and copy the vendored node_modules/ and vendor/ directories to the source root

• deno.compileHook would run deno compile --cached-only --vendor --node-modules-dir <denoCompileFlags> <entrypoints> and then mark built files as stripExclude to avoid removing all the embedded JS code within "compiled" binaries

• Perhaps more hooks would be needed for, for example, running Deno tasks like deno task build

[antholeole]

Hello! I tried this PR out to build a deno package and unfortunately ran into errors. I'm trying out deno for the first time with this PR so this may be user error.

Here's the commit that tries this package: antholeole/home-server@8cb9a50

when building nix build .#server, I get the following error:

Error getting response at https://registry.npmjs.org/@tldraw%2fstate for package "@tldraw/state": An npm specifier not found in cache: "@tldraw/state", --cached-only is specified.

I may attempt to debug further but leaving this here for future readers.

As for the API this is very usable and easy, thanks for the work you did here.

[pluiedev]

Superseded by #407434