Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLI
Assigneesstack72

Relationships

#236 Extension ecosystem: shared utility library, version sync tooling, and HTTP resilience patterns

Opened by webframp · 5/5/2026· Shipped 5/23/2026

Summary

Analysis of 33 published swamp extensions reveals systemic patterns that could be addressed at the platform or tooling level to improve extension quality across the ecosystem.

1. No shared utility library for extensions (HIGH)

Extensions in monorepos (and across the ecosystem) independently reinvent:

  • Command execution wrappers (Deno.Command with timeout/piping) — 6+ copies across extensions
  • HTTP clients with auth, pagination, error handling — 4 separate implementations
  • Time parsing (parseRelativeTime for "1h", "30m", "2d" strings) — 5 identical copies
  • String sanitization utilities

Recommendation: Publish a @swamp/extension-utils package (or document a recommended pattern) providing:

  • runCommand(cmd, args, {timeout, env}) — subprocess execution with timeout
  • fetchWithRetry(url, opts) — HTTP fetch with retry, timeout, rate-limit handling
  • parseRelativeDuration(str) — duration string parser
  • paginateApi(fetcher, opts) — generic async pagination iterator

2. Version drift between manifest.yaml and model exports (HIGH)

14 extensions examined had mismatched versions between manifest.yaml and the version string exported in their TypeScript model files. This suggests manifest versions are bumped independently of code changes.

Recommendation:

  • Add a swamp extension validate check that compares manifest version to exported model versions
  • Or eliminate the model-level version export in favor of the manifest as single source of truth
  • Consider adding this to swamp extension quality scoring

3. tags vs labels inconsistency (MEDIUM)

4 extensions use tags: in manifest.yaml while 27 use labels:. One extension has neither. The schema accepts both but this creates confusion.

Recommendation:

  • Emit a deprecation warning when tags: is used
  • Or add a swamp extension fmt auto-fix that normalizes tagslabels
  • swamp extension quality should flag this

4. No HTTP resilience in hand-rolled fetch wrappers (MEDIUM)

None of the examined fetch-based API clients implement retry, exponential backoff, timeout, or rate-limit (429) detection. A single transient error fails the entire operation.

Recommendation:

  • Document recommended HTTP patterns in extension authoring guide
  • Consider publishing a fetch wrapper as part of shared utilities
  • swamp extension quality could flag raw fetch() calls without error handling patterns

5. Wheelshop integration for extension authoring (LOW)

@bixu/wheelshop is effective at finding community alternatives to hand-rolled code. It could be integrated into the extension quality pipeline:

  • During swamp extension quality, scan for common reinvented patterns
  • Suggest wheelshop searches for detected patterns
  • Add a "dependency hygiene" score to the quality rubric

Environment

  • CLI: 20260504.233645.0-sha.430c1535
  • Extensions analyzed: 33 across aws, cloudflare, redmine, gitlab, github, network, system, terraform, sre, vault, datastore, driver categories
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 7 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

5/23/2026, 1:01:48 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack725/22/2026, 10:33:50 PM
Editable. Press Enter to edit.

stack72 commented 5/22/2026, 10:40:29 PM

Thanks for the thorough analysis across the ecosystem @webframp — really useful data.

After review, here's where we've landed on each item:

1. Shared utility library — not planned. In an AI-native ecosystem, the duplication is actually a feature. Each extension is self-contained and independently deployable. A shared library creates coupling — every breaking change requires coordinating across all consumers, and the slight divergences between each extension's needs (different timeout semantics, different env handling, different auth patterns) mean a "common" wrapper quickly becomes a lowest-common-denominator abstraction. An agent writing 10 lines of purpose-built code per extension is cheaper to maintain than a shared dependency matrix across 33+ extensions.

3. tags vs labels — not planned. We standardized on labels deliberately to be provider-agnostic — tags is an overloaded term. The manifest schema already only accepts labels, so this is resolved.

4. HTTP resilience patterns — not planned. Same reasoning as #1. Every API has different auth, pagination, and retry semantics. A shared fetch wrapper would either be too generic to be useful or too opinionated to fit all cases. Extension authors should handle this per-integration.

5. Wheelshop integration — already done. This is already in place.

2. Version drift validation — planning. This is the clear winner. A validation check comparing manifest version to exported model versions is low-cost, self-contained, and catches real bugs. We'll plan this as a quality scorer addition.

stack72 commented 5/23/2026, 1:01:55 AM

Thanks @webframp for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

webframp commented 5/24/2026, 3:11:39 AM

I get it. No cascading breakage but no cascading fixes either without sufficient prompting or skills. The boundary moves and we need to solve the challenges somewhere else, thanks for looking!

Sign in to post a ripple.