Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

Relationships

#3869 extension fmt (and any command) creates or rewrites deno.lock when the extension lives in the repo's loaded extensions/ dir

Opened by skunk-ape · 10/23/2026

Since swamp-club#3717, extension fmt reads the module graph with the lock read-only (--frozen, or --no-lock when there is no lock), as push and quality do since #3613. But when the extension sits in the repo's own loaded extensions/ directory (the tutorial layout), the extension loader that runs at startup bundles with Deno's default lock handling, so the lock is still written.

Observed on swamp 20261023.183232.0-sha.c0e1560b:

  • Fresh repo, extension with deno.json and no deno.lock: swamp extension fmt --check creates extensions/behaviors/deno.lock. swamp model type search alone also creates it.
  • Stale lock (deno.json gained an import after the lock was written): swamp extension fmt --check rewrites the lock (sha256 changes) and prints no WRN line, so the stale-lock warning fmt is meant to give never appears, and push afterwards sees a lock it did not ask the author to update.
  • Outside the loaded dir, fmt leaves the lock byte-identical in both cases, as intended.

Expected: no swamp command writes or rewrites an extension's deno.lock unless the author asks for it (deno install). At minimum, the loader should read the lock read-only for extensions under the loaded dir, so fmt, quality and push behave the same wherever the extension lives.

Found while documenting dependency trust for swamp-club#3725; the manual will scope its claim to fmt's own graph read until this is fixed.

02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

10/23/2026, 9:09:00 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.