Skip to content

feat: add CLI export command for SVG output - #264

Open
creator79 wants to merge 3 commits into
tt-a1i:mainfrom
creator79:feature/cli-svg-export-241
Open

feat: add CLI export command for SVG output#264
creator79 wants to merge 3 commits into
tt-a1i:mainfrom
creator79:feature/cli-svg-export-241

Conversation

@creator79

@creator79 creator79 commented Sep 1, 2026

Copy link
Copy Markdown

Solves #241: The archify deliver command writes the interactive HTML page, and SVG export is only
accessible through the in-page Export menu. This prevents automated documentation workflows, CI/CD pipelines,
and static site generators from obtaining standalone SVG diagrams without browser interaction.

This PR adds a direct CLI command archify export <type> <input.json> <output.svg> that extracts clean,
standalone SVG files with embedded styles, enabling headless automation and integration into build pipelines.

Scope

  • What changed:

    • Added new archify export command in bin/export.mjs
    • Registered export command in bin/archify.mjs with dynamic import
    • Export extracts SVG from rendered HTML and embeds <style> block for standalone rendering
    • Added --format svg, --quality standard|showcase, --repo-root, and --json flags
    • Added comprehensive test suite in test/export-command.test.mjs covering all 5 diagram types
  • What deliberately did not change:

    • Existing render, validate, deliver, and preview commands remain unchanged
    • No modifications to JSON schemas or validation rules
    • No changes to renderer implementations or template.html
    • PNG/WebP export deferred for future implementation (requires browser automation)
  • No unrelated changes: Confirmed. Only added export functionality without touching existing flows.

Stability impact

  • Compatibility and migration risk: None. Pure additive feature with no breaking changes.

  • Renderer, validator, package, or generated-artifact risk: Low. Reuses existing rendervalidate
    extract pipeline. No new rendering logic.

  • Failure behavior and rollback path: Non-zero exit code on failure. Structured JSON receipt available with
    --json flag. Temporary HTML artifacts are cleaned up in finally block.

Tests run

cd archify
node --test test/export-command.test.mjs

Results:
✔ export command extracts SVG from all five diagram types (4876.3716ms)
✔ export command supports --json flag (689.6942ms)
✔ export command supports --quality flag (1185.2812ms)
✔ export command rejects unsupported formats (106.1629ms)
✔ export command fails with invalid input (283.1483ms)
✔ exported SVG is deterministic for identical input (1764.0368ms)
✔ export command creates output directory if missing (767.1374ms)

ℹ tests 7
ℹ pass 7
ℹ fail 0
ℹ duration_ms 9823.3903

Manual verification:
node bin/archify.mjs export architecture examples/web-app.architecture.json /tmp/web-app.svg
node bin/archify.mjs export workflow examples/agent-tool-call.workflow.json /tmp/workflow.svg --quality
showcase
node bin/archify.mjs export sequence examples/cache-miss-request.sequence.json /tmp/sequence.svg --json

All commands completed successfully with valid SVG output containing embedded styles and proper xmlns
attribute.

Visual evidence

Not applicable. This is a CLI enhancement that extracts existing rendered SVG content. The visual output
matches the HTML viewer's diagram exactly.

Generated artifacts

None. No changes to documentation, gallery pages, or archify.zip required. The export command operates on
existing examples and user-provided JSON specifications.

Checklist

- [x] I used a minimal focused change and preserved existing typed JSON behavior unless the issue requires a
  contract change.
- [x] I ran the relevant targeted tests and npm test in archify/.
- [x] I added or updated a regression test for behavioral changes.

All commands completed successfully with valid SVG output containing embedded styles and proper xmlns
attribute.

Visual evidence

Not applicable. This is a CLI enhancement that extracts existing rendered SVG content. The visual output
matches the HTML viewer's diagram exactly.

Generated artifacts

None. No changes to documentation, gallery pages, or archify.zip required. The export command operates on
existing examples and user-provided JSON specifications.

Checklist

- [x] I used a minimal focused change and preserved existing typed JSON behavior unless the issue requires a
  contract change.
- [x] I ran the relevant targeted tests and npm test in archify/.
- [x] I added or updated a regression test for behavioral changes.
- [x] I checked generated artifacts and package freshness when their sources changed.
- [x] I removed secrets, private repository content, and customer data from fixtures and screenshots.

@tt-a1i  @yunaremaia  @claude  can u please review it 

creator79 and others added 2 commits September 1, 2026 15:39
Adds 'archify export' command to extract SVG from diagrams without
requiring HTML viewer interaction. Enables automated documentation
workflows and CI/CD integration.

- Add bin/export.mjs with SVG extraction and embedded styles
- Update bin/archify.mjs to register export command
- Add comprehensive test coverage for all diagram types
- Support --format, --quality, --repo-root, and --json flags

Fixes tt-a1i#241
@user01010111

Copy link
Copy Markdown

Hmm... SVG output is definitely worth adding, but I don’t think this implementation is quite the right fit yet, though. It creates a second rendering path alongside deliver, duplicates several CLI and rendering helpers, and extracts the SVG and CSS from generated HTML with regular expressions. That bypasses guarantees the existing delivery and Viewer export paths already provide, including frozen-input validation, safe and atomic replacement, rollback, canonical backgrounds and sizing, filtered export styles, dual-theme output, and complete structured errors.

The current tests show that a file is created consistently, but they don’t establish that it is the same diagram as the HTML/Viewer output. The advertised PNG and WebP options also return unsupported errors, which makes the public surface broader than the implementation.

I think the better fit is to share the existing standalone-SVG finalisation between Viewer export and deliver --format svg, while keeping the established delivery pipeline around it. That gives us one canonical rendering path and leaves room for another format to reuse the pipeline later, without building a plugin framework before we need one.

I will (with respect to your work thus far, and not in light of it) write up a PR that I think is a better fit, and leave it to the maintainers to make a call ultimately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants