Is building a binary-reproducible vendor directory feasible?

[charles-dyfis-net]

Howdy!

I'm working with the Nix build system; one of its characteristics is that for security reasons, only build steps that know up-front what they expect their outputs to be (provided as a hash) are allowed network access.

Unfortunately, vendor/ directories include meta.json files that include information about which library versions were available at download time, including those not requested by the lockfile. This means that building a vendor directory out of a lockfile has unstable output, expected to change over time, so using the vendor directory's hash is expected to break whenever the set of library versions available for download is updated.

This specific problem I could work around by just deleting every entry from "versions" that isn't actively in use, and pointing "latest" only at the selected item. That said -- has anyone else gone down this path, to know if there are more gotchas waiting? Alternatively, is there an intended path to build a completely binary-reproducible vendor directory from a lockfile?

[anntnzrb]

Binary-reproducible vendor directories aren't currently feasible because JSR's meta.json includes ALL available versions at download time, not just the lockfile version. Your suggested workaround is correct: post-process the vendor directory to remove extra version entries from meta.json and point 'latest' only to the used version. Alternatively, use deno compile which properly bundles all metadata for offline use.