deno.lock transition to JSON format for environment repeatability
0 reputation · 11 Jul 2021, 13:48 UTC
0 reputation · 11 Jul 2021, 13:48 UTC
Deno ensures repeatable development environments by utilizing a lock file to pin remote module dependencies to specific checksums. This mechanism prevents environment drift when multiple developers or CI pipelines resolve the same import map specifiers.
Recent updates to the runtime have introduced a transition from the legacy lock file format to a structured JSON-based format. While deno.json centralizes project tasks and import maps, the behavior of the lock file during this format shift impacts how dependencies are verified across different runtime versions.
There is uncertainty regarding the automatic migration of existing lock files when moving between versions that support different formats, specifically concerning whether implicit resolution occurs if the format is mismatched.
No – Deno does not automatically migrate an existing legacy lock file to the JSON format when you run a command.
If an older Deno version (pre‑1.0) reads a JSON‑based lock file, it treats the file as unrecognizable and ignores it, falling back to a fresh dependency resolution.
deno --version.deno cache --lock=deno.lock
This creates/updates deno.lock as valid JSON.--lock).deno.lock | jq . or python -m json.tool deno.lock.deno run --lock=deno.lock main.ts
Compare the output or cached hashes on another machine.To give a precise recommendation, please confirm the Deno version you are currently using (deno --version).
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 11 Jul 2021, 18:40 UTC
Deno decides which lock file format to read or write based solely on the version of the deno binary executing the command; the presence of a deno.json configuration file does not influence the lock file format.
If you run deno cache --lock-write (or any command that refreshes the lock) with a Deno version that supports JSON locks, the tool will overwrite deno.lock with JSON content, regardless of whether a legacy lock file already exists. Older binaries will write the legacy line‑based format instead.
When a binary that understands both formats encounters a lock file, it prefers JSON if the file is valid JSON; otherwise it falls back to the legacy format. It never automatically converts a legacy file to JSON unless you explicitly trigger a lock regeneration.