Skip to main content
← Back to list
01Issue
BugShippedSwamp CLIPublic
Assigneesstack72

Relationships

#1855 paths.base manifest with nested model path breaks registry metadata

Opened by funsaized · 8/26/2026· Shipped 8/27/2026

Description

A valid extension manifest using paths.base: manifest with a nested model entry publishes successfully, but the archive places the source at models/models/project.ts and registry metadata extraction looks for models/project.ts. The published extension is pullable, but contentTypes and contentMetadata.models remain empty, so swamp.club does not display its model methods.

Reproduction

Use this repository layout:

manifest.yaml
models/project.ts
README.md
LICENSE

With this manifest entry:

paths:
  base: manifest
models:
  - models/project.ts

Then run:

swamp extension quality manifest.yaml --json
swamp extension push manifest.yaml --dry-run --json
swamp extension push manifest.yaml --yes --json
swamp extension info @funsaized/npm --json

Actual behavior

  • Push and dry-run accept the manifest.
  • Pull extracts the source as .swamp/pulled-extensions/@funsaized/npm/models/models/project.ts.
  • Local quality analysis fails with Module not found .../extension/models/project.ts.
  • The published @funsaized/npm@2026.08.26.1 reports empty contentTypes, contentNames, and contentMetadata.models.
  • Its swamp.club page consequently omits the Models and method sections.

Expected behavior

Either nested paths accepted with paths.base: manifest should be indexed at their actual archive location, or manifest validation/dry-run should reject this layout with an actionable error requiring a flat typed entry. Local quality, server scoring, pull layout, and registry metadata extraction should agree.

Workaround

Move the model beside the manifest and publish it as models: [project.ts], which produces the canonical archive path models/project.ts and allows local quality scoring to pass.

Environment

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 7 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/27/2026, 12:31:49 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/26/2026, 11:49:37 PM
Editable. Press Enter to edit.

funsaized commented 8/26/2026, 9:10:12 PM

Follow-up after publishing the flat-layout workaround:

  • Published @funsaized/npm@2026.08.26.2 with paths.base: manifest and models: [project.ts].
  • Push succeeded with modelCount: 1 and bundleCount: 1.
  • Pull confirms the canonical source path .swamp/pulled-extensions/@funsaized/npm/models/project.ts (no doubled models/models path).
  • Local quality passes at 100%, and all 19 extension tests pass.
  • Despite that, swamp extension info @funsaized/npm --json still returns empty contentTypes, contentNames, and contentMetadata.models; the public page still omits Models/methods.

This disproves the nested archive path as the sole cause. The server-side metadata extractor is still failing or discarding this valid model even at the canonical path. Please inspect indexing diagnostics for extension id 38c69034-64d1-4d28-9620-853da076a79f, version 2026.08.26.2.

funsaized commented 8/26/2026, 9:12:05 PM

Confirmed root cause from the official publishing tutorial and local dry-run diagnostics:

The model used const VERSION = "2026.08.26.2" with model.version: VERSION. This is valid at runtime (swamp model type describe loads all methods), passes fmt/quality/tests/push, and pulls successfully, but the static publishing metadata extractor cannot resolve the identifier.

Before replacing it, dry-run logged:

Models (1):
  "project.ts" ("project.ts")

After changing only model.version and upgrades[].toVersion to literal CalVer strings, dry-run logs:

Models (1):
  "@funsaized/npm/project" ("project.ts")
    Global Arguments:
      ...

The registry therefore published the model bundle but omitted contentTypes/contentMetadata because metadata extraction silently failed on a non-literal version. Suggested fix: validation/dry-run should reject non-literal model.version, or the extractor should resolve top-level string constants. At minimum, push should not succeed while displaying the source filename as the model type.

stack72 commented 8/27/2026, 12:32:12 AM

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

Sign in to post a ripple.