Recommend or manage lockfile strategy for extension model npm dependencies

[bixu]

Problem

When extension models use Deno-style npm: import specifiers (e.g. import { z } from "npm:zod@4"), the repo's deno.lock does not include the npm dependency resolution. Agentic code reviewers (e.g. pi-judge) flag this as a reproducibility gap and suggest regenerating the lockfile — but the fix can't be cleanly applied.

Current behavior

1. Extension models import npm packages via npm:zod@4 specifiers
2. Swamp resolves these internally via its own Deno runtime
3. The repo's deno.lock has no entry for these npm dependencies
4. Running deno cache to fix it fails without a deno.json, or requires --node-modules-dir=auto which also resolves unrelated package.json dependencies (e.g. @anthropic-ai/claude-code and all its optional deps), bloating the lockfile

Proposed solution

One of:

• Swamp manages a lockfile for extension model dependencies (e.g. during swamp extension push or swamp repo index)
• Recommend a deno.json pattern scoped to extensions/ with explicit imports, so users can run deno cache cleanly
• Document that deno.lock is not expected to cover swamp model deps, so agentic reviewers and humans know to ignore this

Alternatives considered

• Adding npm deps to package.json — wrong tool for Deno-style imports
• Creating a root deno.json — pulls in unrelated deps from package.json in the same directory

Additional context

Discovered during PR review of swamp extension models in https://github.com/hivemq/hivemq-terraform-harvester/pull/69. An automated multi-model reviewer flagged the missing npm:zod@4 resolution in deno.lock as a medium-severity reproducibility issue.

[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.

[bixu]

Update: package.json in repo root breaks deno bundle for extensions

We hit a concrete breakage from this issue today. When a package.json exists in the repo root (in our case, it only contains @anthropic-ai/claude-code), Deno auto-detects nodeModulesDir mode and expects all npm dependencies to be in node_modules/ — including the npm: specifiers from extension models.

This means swamp extension push and swamp model method run both fail with:

error: Could not find a matching package for 'npm:@octokit/rest@22.0.1' in the node_modules directory.
Ensure you have all your JSR and npm dependencies listed in your deno.json or package.json,
then run `deno install`.

The extension was previously published and working fine — the breakage started when package.json was added to the repo root for an unrelated tool.

Workaround

Adding a deno.json at the repo root with {"nodeModulesDir": "none"} fixes it by telling Deno to use its global cache instead of node_modules/. This restores the previous behavior where npm: specifiers in extension models resolve from Deno's global cache.

Why this matters

The original analysis says the lockfile gap is cosmetic, but this shows a real failure mode: any repo that gains a package.json for non-Deno tooling will silently break all extension bundling. The --no-lock flag doesn't help here — this is a module resolution strategy change, not a lockfile issue.

Possible fixes at the swamp level:

1. Have swamp repo init / swamp repo upgrade auto-generate deno.json with "nodeModulesDir": "none"
2. Have the bundler explicitly set DENO_NO_PACKAGE_JSON=1 or pass --node-modules-dir=none to deno bundle
3. Document the workaround in the extension model skill

[bixu]

More context: I asked Swamp to avoid reinventing octokit because I felt the lib is likely very stable/bug-free and covering all of the gh api would be error-prone even in Swamp.