Enable the report-generation server to load and run custom reporters—including community npm packages (e.g., monocart-reporter) and in-house reporters—when generating/aggregating Playwright results.
This complements the “built-in reporters” #99 feature and lets teams output additional formats (HTML dashboards, junit/xunit variants, CSV, custom JSON, etc.) and integrate with third-party platforms.
⸻
Background & Goals
• Teams increasingly rely on extended reporters beyond Playwright built-ins (e.g., Monocart, Allure bridges, internal dashboards).
• Today, to obtain those artifacts, tests must be re-run with different --reporter settings or a separate post-processing step outside our server.
• Goal: allow the server to discover, install, configure, and execute custom reporters as part of the aggregation flow, producing artifacts alongside the merged report.
⸻
Scope
1. Loading: The server can dynamically load external reporter modules by name or path.
2. Execution: The server invokes them with merged test results or with a faithful Playwright-like event stream (see Option B below).
3. Artifacts: Reporter outputs are written to a configured output directory per run; links appear in the final HTML index.
4. Security & Stability: Sandboxing and resource limits to avoid unsafe code impacting the server.
Open Questions
• Do we want to officially support dynamic npm install, or require pre-bundled/whitelisted reporters only?
Enable the report-generation server to load and run custom reporters—including community npm packages (e.g., monocart-reporter) and in-house reporters—when generating/aggregating Playwright results.
This complements the “built-in reporters” #99 feature and lets teams output additional formats (HTML dashboards, junit/xunit variants, CSV, custom JSON, etc.) and integrate with third-party platforms.
⸻
Background & Goals
• Teams increasingly rely on extended reporters beyond Playwright built-ins (e.g., Monocart, Allure bridges, internal dashboards).
• Today, to obtain those artifacts, tests must be re-run with different --reporter settings or a separate post-processing step outside our server.
• Goal: allow the server to discover, install, configure, and execute custom reporters as part of the aggregation flow, producing artifacts alongside the merged report.
⸻
Scope
1. Loading: The server can dynamically load external reporter modules by name or path.
2. Execution: The server invokes them with merged test results or with a faithful Playwright-like event stream (see Option B below).
3. Artifacts: Reporter outputs are written to a configured output directory per run; links appear in the final HTML index.
4. Security & Stability: Sandboxing and resource limits to avoid unsafe code impacting the server.
Open Questions
• Do we want to officially support dynamic npm install, or require pre-bundled/whitelisted reporters only?