Provide guidance on deno.lock file management

[bixu]

Problem Statement

When swamp initializes a repository with extension models, a deno.lock file is generated in the project root. There is no guidance on whether this file should be:

1. Checked into version control or added to .gitignore
2. Located in the project root or scoped under .swamp/ like other swamp runtime artifacts

This creates uncertainty for users setting up swamp in their repos. The .gitignore entries added by swamp init cover .swamp/data/, .swamp/outputs/, .swamp/secrets/, etc., but say nothing about deno.lock.

Proposed Solution

Provide clear guidance on deno.lock management. Options to consider:

• If it should be committed: Document this in swamp init output or in the generated .gitignore comments (e.g., # Keep deno.lock checked in for reproducible builds)
• If it should be ignored: Add deno.lock to the .gitignore entries that swamp init generates
• If it should live under .swamp/: Move the lockfile scope so it's generated inside .swamp/ rather than polluting the project root, consistent with how other swamp artifacts are organized

Alternatives Considered

• Users could decide on their own, but this leads to inconsistency across teams and projects
• A note in swamp documentation would help, but inline guidance during swamp init would be more discoverable

Additional Context

The lockfile currently tracks JSR/npm dependencies used by extension models (e.g., @std/yaml, zod). For application repos (not libraries), committing the lockfile is generally recommended for reproducibility, but the root-level placement feels out of place when swamp otherwise keeps its artifacts under .swamp/.

[github-actions]

Hi @bixu, thanks for opening this issue!

We appreciate you taking the time to report it. A maintainer will review it as soon as possible.

In the meantime, please make sure you've included all relevant details (steps to reproduce, expected vs actual behaviour, swamp version, etc.) to help us triage it quickly.

[stack72]

Root Cause

The bundleExtension() function in src/domain/models/bundle.ts runs deno bundle as a subprocess without setting a cwd, so it inherits the user's current working directory. Deno's default behavior is to auto-discover/create a deno.lock in the CWD (or next to a discovered deno.json). This is what creates the lockfile in the user's project root.

Fix

Add --no-lock to the deno bundle invocation. This flag ("Disable auto discovery of the lock file") is supported by deno bundle and prevents the lockfile from being created.

The lockfile isn't needed for extension bundling because:

• Extension bundles are already cached in .swamp/bundles/ with mtime-based invalidation
• Users specify explicit versions in their npm: specifiers (e.g. npm:@aws-sdk/client-ec2@3.x)
• The bundled JS output is what provides reproducibility, not the lockfile

One-line change in src/domain/models/bundle.ts — add "--no-lock" to the args array before "--external".

[stack72]

Updating my earlier comment with one additional note:

Since the fix removes lockfile creation, users should pin explicit versions in their npm: import specifiers to ensure reproducible builds. For example:

// Good - pinned version
import { EC2Client } from "npm:@aws-sdk/client-ec2@3.750.0";

// Avoid - unpinned, could resolve differently on each bundle
import { EC2Client } from "npm:@aws-sdk/client-ec2";

We should document this guidance as part of the extension model documentation / swamp-extension-model skill, and consider emitting a warning during bundling if we detect unpinned specifiers.