`swamp model type describe` shows no methods when model uses local imports

[bixu]

Description

When an extension model uses local imports (companion .ts files in a subdirectory), swamp model type describe returns the type with globalArguments but an empty methods array. The bundler appears to not resolve the imports into the main model.

Steps to Reproduce

1. Create a model with local imports:

   extensions/models/gcp_resourcemanager.ts          # main model, imports from ./gcp_resourcemanager/
   extensions/models/gcp_resourcemanager/client.ts    # GCP API client
   extensions/models/gcp_resourcemanager/methods.ts   # business logic (methods imported by main)
   extensions/models/gcp_resourcemanager/types.ts     # shared types
   

2. Create a manifest:

   manifestVersion: 1
   name: "@hivemq/gcp/resourcemanager"
   version: 2026.03.25.1
   models:
     - gcp_resourcemanager.ts

3. Run swamp model type describe @hivemq/gcp/resourcemanager --json

Expected: JSON includes methods array with all methods defined in the model.

Actual: JSON includes globalArguments and resources but methods is empty or missing.

Additional Context

• swamp extension push --dry-run lists the companion files as separate model entries, suggesting the bundler treats them as independent models rather than imports of the main model
• This works locally when .swamp/bundles/ has been populated by prior runs, but fails in fresh CI checkouts
• The @hivemq/gcp/iam extension has the same structure and exhibits the same behavior in CI
• Workaround: none found so far. swamp model type search, swamp extension fmt, and swamp extension push --dry-run all fail to produce a working bundle

Environment

• swamp: installed via brew install systeminit/tap/swamp in CI (latest)
• OS: Ubuntu 24.04 (GitHub Actions runner)
• Deno: v2.x

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

🔍 Triage started — fetching issue context

[stack72]

📋 Classified as bug (high) — The bundler's content metadata extractor uses regex-based static analysis (extractMethods in extension_content_extractor.ts) that only matches inline 'methods: {' patterns. When a model imports methods from companion files and uses shorthand property syntax ('methods,' or 'methods: importedMethods'), the regex fails to find any methods. Additionally, extractContentMetadata receives allModelFiles (entry points + companions), causing companion files to potentially appear as separate model entries in extension push --dry-run. The bundleWithCache mtime check uses strict greater-than, which can cause unnecessary re-bundling when pulled extension archives have equal mtimes for source and bundle files.

[stack72]

📝 Implementation plan generated (v1) — Three interconnected bugs cause models with local imports to show empty methods: (1) extractContentMetadata passes all model files including companions to the static analyzer, (2) extractMethods regex only matches inline methods and misses imported/shorthand methods, (3) bundleWithCache strict mtime comparison causes unnecessary re-bundling after fresh pulls.

[stack72]

🔄 Plan revised (v2) — incorporated feedback round 1

[stack72]

Approved Implementation Plan (v2)

Summary: Primary bug: model loading errors are silently swallowed because loadUserModels runs at CLI startup before logging is initialized. When a model fails validation, the user sees only 'type not found' with no explanation. Secondary: extractContentMetadata regex cannot handle imported methods, affecting extension push --dry-run. Tertiary: bundleWithCache mtime strict comparison causes unnecessary re-bundling.

DDD Analysis

Primary fix is in the CLI adapter layer (src/cli/mod.ts) — move error surfacing after logging init. Secondary fix in extensions domain (content extractor). Tertiary fix in models domain (bundle cache).

Implementation Steps

1. Model loading (loadUserModels) runs before logging is initialized in CLI startup. When a model fails validation (bad resources spec, incompatible zod version, etc.), the error is silently swallowed — the user just sees 'type not found' with no explanation. Fix by collecting loading errors during startup and emitting them after logging is initialized. (risk: Low — only changes when errors are displayed, not how models are loaded)
2. extractMethods in extension_content_extractor.ts only matches inline 'methods: {' pattern. When methods are imported from companion files (shorthand 'methods,' or 'methods: importedVar'), the regex returns []. Also pass only modelEntryPoints (not allModelFiles) to avoid companion files being falsely identified as models. (risk: Medium — regex extraction is inherently fragile)
3. Change mtime comparison from strict > to >= so equal mtimes (common after archive extraction) use the cached bundle instead of triggering unnecessary re-bundling. (risk: Low)
4. Test that model loading errors are surfaced. Test extractMethods with shorthand/imported methods. Run full test suite. (risk: Low)

Files

• src/cli/mod.ts
• src/domain/extensions/extension_content_extractor.ts
• src/libswamp/extensions/push.ts
• src/domain/models/user_model_loader.ts
• src/cli/mod_test.ts
• src/domain/extensions/extension_content_extractor_test.ts

Testing Strategy

Test that model loading errors are surfaced after logging init. Test extractMethods with shorthand/imported methods patterns. Verify with reproduction fixture that a model with validation errors produces a visible warning.

Potential Challenges

• Model loading must stay fast — errors should be collected and deferred, not block startup
• Regex extraction for imported methods may need to fall back to reading bundled JS
• Reporter's actual validation error is unknown — surfacing errors will help them self-diagnose

Incorporated 1 round(s) of feedback.

Approved via swamp @si/issue-lifecycle