Lock File Auto‑Update vs. Manual Locking: Trade‑off for Deterministic Deno Builds

Goal: achieve a repeatable Deno development environment that guarantees the same dependency versions across machines and CI runs while minimizing manual overhead.

Constraint: teams can either rely on Deno to automatically refresh deno.lock on every execution or maintain a static lock file that is updated only via an explicit deno cache --lock step; the former risks drift in CI if the lock file changes unexpectedly, whereas the latter may lock out legitimate updates unless a manual step is remembered. The unresolved behavior is whether Deno should adopt automatic lock‑file updates by default or require an explicit command to avoid inconsistency.

• Should Deno enable automatic lock‑file updates on every run when dependencies change, or keep the lock file immutable unless an explicit command is issued?
• How does each approach affect reproducibility and CI pipeline reliability?
• What practical trade‑offs exist between repository size, network dependence, and update discipline?