Question
Deno module cache invalidation limits when remote dependencies update
Dev Nea
0 reputation · 27 Apr 2022, 08:11 UTC
115.5K views1
Loading…
0 reputation · 27 Apr 2022, 08:11 UTC
Deno caches all remote modules under DENO_DIR and reuses them across runs unless a module hash changes or --reload is supplied. The cache does not automatically invalidate based on time or upstream modifications.
Ensure that a script always executes with the current version of its remote dependencies without requiring manual intervention before every run.
deno cache --reload forces a full re-fetch, which adds latency and network traffic.DENO_DIR clears all caches globally, affecting unrelated projects.--reload?34775 reputation · 27 Apr 2022, 11:23 UTC
Deno does not automatically expire cached remote modules; it relies on HTTP caching headers or manual intervention.
denojsDENO_DIR (e.g., DENO_DIR=.deno_cache deno run ...) so each project has its own cache directory. This isolates invalidation without affecting other projects.deno cache --reload <specifier> for only the modules you want to refresh; the command accepts one or more URLs and will re‑fetch just those.import "https://example.com/mod.ts" { integrity: "sha256‑…" }) makes Deno treat a hash mismatch as an error; you must update the hash manually when you want a new version. It does not trigger an automatic refresh.deno.lock file records the exact versions resolved at lock time. Deno will reuse those versions unless you delete the lock file or run deno cache --reload (or deno upgrade) to regenerate it. The lock file itself does not cause Deno to check for updates.As of the current Deno release (1.x series), there is no built‑in TTL or background validation feature. The Deno team has discussed exposing cache‑control options via CLI flags or a configuration file, but no concrete timeline has been announced. The recommended approach remains to rely on proper HTTP caching headers from the remote server or to version your imports (e.g., include a version segment in the URL).
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 27 Apr 2022, 14:12 UTC
While project-specific DENO_DIR paths solve the isolation problem, it is important to highlight the risk of using mutable URLs (such as /main or /latest) in production environments. Because Deno's cache is content-addressable and does not poll for updates, two different developers running the same script may execute different code if one cached the module before a remote update and the other after.
To ensure deterministic builds without relying on --reload, the most reliable pattern is to use immutable versioning in the URL (e.g., a specific semantic version or a git commit hash). You can verify this behavior by:
deno.lock file to pin current hashes.