Deno remote module cache vs CI pipeline: forcing revalidation of unversioned HTTPS imports without --reload wiping everything

Integration boundary

A Deno service imports a handful of remote modules over plain HTTPS URLs (not a versioned registry like deno.land/x with @ tags). Locally and in CI, Deno caches these downloads under DENO_DIR keyed by URL, so once a URL is fetched it is not requested again on later runs. The upstream occasionally publishes fixes at the same URL, and the cached copy keeps being used, which is the stale-result behavior I need to design around.

Constraints and uncertainty

Running with --reload and no arguments re-fetches every remote dependency, which is slow in CI and can silently pull breaking upstream changes from unrelated modules. A lockfile verifies integrity of recorded bytes but says nothing about freshness. Vendoring would work but changes the team's review workflow, so I would prefer to keep remote imports. Assume a current Deno 2.x runtime; flag behavior should be verified against the installed version.

Questions

• Is scoping reload to specific specifiers (e.g. --reload=https://example.com/mod.ts) the intended way to refresh one stale module while leaving the rest of DENO_DIR untouched, and does it propagate to that module's own remote transitive imports?
• Is there any supported TTL, conditional-request, or cache-metadata mechanism for remote deps, or is specifier-scoped reload the only revalidation path?
• For CI reproducibility, is warming DENO_DIR plus a lockfile considered sufficient, or is vendoring the only defensible option for mutable URLs?