Skip to content

Plugin validation entrypoints for CLI and dashboard upload checks #36

@FTMahringer

Description

@FTMahringer

Problem / Motivation

SYNAPSE now has real backend plugin fixture packaging and lifecycle validation paths, but there is no user-facing way to validate a plugin JAR before install or publication. That makes plugin authoring, marketplace moderation, and future dashboard uploads weaker than they need to be.

Proposed Solution

Add a plugin validation surface that reuses the existing backend/plugin validation logic and exposes it through operator tooling.

Initial shape:

  • CLI command: synapse plugins validate <path-to-plugin.jar> or synapse plugins check <path-to-plugin.jar>
  • Command should run all available automated checks and return a structured pass/fail summary
  • Checks should include, where applicable:
    • safe JAR path/file validation
    • manifest presence and parseability
    • manifest schema validation
    • plugin type validation
    • entry point validation
    • plugin API compatibility checks
    • dependency/conflict checks
    • bytecode sandbox scan / forbidden references
    • packaging/runtime metadata checks needed by the loader
  • Later follow-up:
    • dashboard upload/tester UI that accepts a plugin JAR and shows the same validation results before install/publication
    • optional machine-readable JSON output from the CLI for CI/plugin publishing workflows

This should build on the current backend validation/runtime logic instead of inventing a separate validator stack.

Alternatives

  • backend-only validation during install
    • weaker UX because plugin authors get feedback too late
  • dashboard-only upload validation
    • misses CLI/local development and CI use cases
  • separate standalone validator implementation
    • risks drift from the actual runtime checks

Priority

Medium

Notes

Recommended namespace direction:

  • generic install stays under synapse plugins install
  • plugin-specific validation fits under synapse plugins validate <jar>
  • later type-specific flows can still live under synapse plugins skills ..., synapse plugins channels ..., etc.

The dashboard upload/tester should reuse the same backend validation result model as the CLI-facing path where possible.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestfuture ideaIdea for a future feature, not planned yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions