Summary
Introduce a validation pipeline within the orchestrator to verify widget invariants after the build.
The initial motivation is to validate that widgets are correctly prepared for CSS prefixing, but the solution should provide a generic validation framework capable of supporting additional validation rules over time.
Problem
The orchestrator currently validates contracts and build artefacts, but it does not validate the behaviour or structure of built widgets.
As a result, regressions such as missing host classes or incorrect CSS scoping can only be discovered at runtime.
This represents a validation gap.
Proposal
Introduce a validation pipeline executed after a widget has been built.
Each validation should be independent and report its result as part of the orchestrator build report.
Example:
Build Widget
│
▼
Run Validations
│
▼
Validation Report
Initial Validation
Validate that the widget host is correctly prepared for CSS prefixing.
Example:
This validation may require rendering the widget in a virtual DOM, but the framework should not depend on any specific validation implementation.
Future Validations
Potential validation rules include:
- Host element contains the expected widget class.
- CSS selectors have been correctly prefixed.
- CSS bundle exists.
- SSR renders successfully.
- CSR mounts successfully.
- SSR and CSR remain compatible.
- Detect global CSS leakage.
- Validate runtime assumptions.
- Accessibility validation.
- Widget contract consistency.
Goals
- Detect widget regressions before deployment.
- Provide consistent quality checks across all widgets.
- Make it easy to introduce new validation rules.
- Integrate validation results into the existing orchestrator reporting.
Notes
The objective is not to validate CSR specifically.
The objective is to establish a reusable widget validation framework, where CSR rendering is simply one possible mechanism used by individual validation rules.
Summary
Introduce a validation pipeline within the orchestrator to verify widget invariants after the build.
The initial motivation is to validate that widgets are correctly prepared for CSS prefixing, but the solution should provide a generic validation framework capable of supporting additional validation rules over time.
Problem
The orchestrator currently validates contracts and build artefacts, but it does not validate the behaviour or structure of built widgets.
As a result, regressions such as missing host classes or incorrect CSS scoping can only be discovered at runtime.
This represents a validation gap.
Proposal
Introduce a validation pipeline executed after a widget has been built.
Each validation should be independent and report its result as part of the orchestrator build report.
Example:
Initial Validation
Validate that the widget host is correctly prepared for CSS prefixing.
Example:
This validation may require rendering the widget in a virtual DOM, but the framework should not depend on any specific validation implementation.
Future Validations
Potential validation rules include:
Goals
Notes
The objective is not to validate CSR specifically.
The objective is to establish a reusable widget validation framework, where CSR rendering is simply one possible mechanism used by individual validation rules.