[EPIC](greenhouse): Dynamic External Plugin Integration System

[ArtieReus]

Description

Currently, Greenhouse only supports hardcoded plugins that are direct dependencies in the monorepo. This epic establishes a dynamic plugin system where external third-party plugins (developed outside the monorepo by other teams/organizations) can be integrated without adding them as direct dependencies to greenhouse or including them in the monorepo source tree. This prevents package vulnerabilities from external sources affecting our security scans, avoids the maintenance burden of tracking third-party code changes, and enables the plugin ecosystem to grow independently without coupling external code into our monorepo. Core plugins (supernova, doop, heureka) developed by the Frontend Engineering Team will remain as monorepo dependencies.

Objectives

• Enable external third-party plugins to be integrated without adding them as greenhouse dependencies or storing them in the monorepo
• Implement a manifest-based system for declaring and validating trusted external plugins
• Enable build-time dynamic fetching and bundling of external plugins from npm packages
• Keep core plugins (supernova, doop, heureka) as monorepo dependencies managed by Frontend Engineering Team
• Provide clear documentation and tooling for external teams to develop and publish plugins
• Maintain runtime plugin loading capability only for successfully fetched and bundled plugins

Acceptance Criteria

• A manifest file system is implemented that declares trusted external third-party plugins (source location, version constraints, integrity checks)
• Build pipeline successfully fetches, validates, and bundles trusted external plugins at image creation time
• Core plugins continue to work as monorepo dependencies (no changes to their development workflow)
• Runtime plugin loader (usePluginLoader.ts) supports both core plugins (static imports) and external plugins (dynamic bundles)
• Failed external plugin fetches during build are gracefully handled (logged, skipped, build continues)
• API integration allows plugin definitions to be exposed conditionally based on available bundled plugins
• External plugin development documentation is complete with examples and guidelines
• No package vulnerabilities from external plugins appear in greenhouse dependency scans
• External plugins are only included in the bundle if successfully fetched from the manifest

Tasks

• Research and design manifest file structure for trusted external plugins (location, schema, validation)
• Research build-time plugin fetching strategies (npm registry integration, version resolution, caching)
• Research where the manifest should live and how it's maintained (repo file, remote endpoint, etc.)
• Implement build script to fetch external plugins from manifest and bundle them into the application
• Modify usePluginLoader.ts to support both core plugins (existing switch) and external plugins (dynamic discovery)
• Update build pipeline/Dockerfile to execute external plugin fetching and handle failures gracefully
• Implement plugin availability detection at runtime (only expose plugins that were successfully bundled)
• Create external plugin development documentation (structure, API contracts, packaging, publishing, registration process)
• Create example external plugin repository demonstrating the development workflow
• Test build process with unavailable external plugins to ensure graceful degradation
• Document security requirements and approval process for adding plugins to the trusted manifest

Dependencies

• Understanding of current Vite build configuration and bundling process
• Access to npm registry or internal package registry where external plugins will be published
• Security review of manifest validation and plugin integrity verification approach
• Definition of plugin API contracts and compatibility requirements

Additional Notes

Current State:

• Core plugins hardcoded in usePluginLoader.ts lines 23-33 with static imports
• Direct workspace dependencies for core plugins in package.json lines 51-53
• All plugins live within the monorepo
• No mechanism to load external third-party plugins

Target State:

• Core plugins (supernova, doop, heureka): remain as monorepo dependencies, managed by Frontend Engineering Team
• External plugins: fetched from external npm packages during docker build or CI build step
• Manifest defines trusted external plugin sources (e.g., @external-org/plugin-name@^1.0.0)
• Build script downloads, verifies, and includes external plugins in bundle
• Runtime discovers available plugins from bundle metadata (core + successfully fetched external)
• Failed external plugin fetches are logged but don't block build

Security Considerations:

• Manifest must include integrity checks (checksums, signatures) to prevent supply chain attacks
• External plugin validation during fetch to ensure compatibility with greenhouse API contracts
• Clear approval process for adding plugins to the trusted manifest
• Consider plugin sandboxing or CSP policies for runtime isolation of external code

Documentation Must Cover:

• Plugin project structure and required exports (mount, unmount, types matching core plugin interface)
• Build and packaging requirements (must be ESM module, size limits, etc.)
• Publishing process to approved npm registry
• How to request registration in the trusted plugin manifest
• Local development workflow for testing external plugins before publishing
• API contract compatibility and versioning strategy
• Approval and security review process for trusted plugin registration