Plugin validation entrypoints for CLI and dashboard upload checks #36

New issue

Open

opened 2026-05-17 11:49:52 +02:00 by FTMahringer · 0 comments

FTMahringer commented

2026-05-17 11:49:52 +02:00

(Migrated from github.com)

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.

## 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.