EDIT: Updated June 2020 with the elements of this that we no longer need styled with strikethrough.

Summary

Long-term goals:

• Ensure package-like parts of Lighthouse are easy to maintain, develop, and consume.
• Facilitate the improvement of report UI components to handle use cases outside of the core report and a more app-like experience remains embeddable.

Long-term Proposal:

• Structure files/folders in a psuedo-lerna packages/* style with core, cli, report, viewer, tracehouse, logger to establish logical delineations between packages.
• Publish lighthouse-logger from packages/logger and publish tracehouse from packages/tracehouse, continue to publish the root as lighthouse initially.
• Eventually publish subpackages of core, cli, and report.
• Other package-like things (dependency graph, sd validation, manifest parser, etc) are first organized in a folder under packages/core/lib before being promoted to a folder in packages/ if demand exists.

Short-term goals:

• Share report UI elements with lighthouse-ci MVP.
• Regularly publish tracehouse as its own package.

Short-term Proposal:

• Break apart the monolithic templates.html and report-styles.css into reusable web components that could be require'd in lighthouse-ci.
• Augment those web components to support diff-modes where applicable.
• Do the file/folder restructuring above and publish a minimal API from packages/tracehouse.

Short-term Hackier Alternatives:

• Fork just the necessary report UI components in the lighthouse-ci repo, copy/paste certain styles for consistency.
• Publish tracehouse straight from lighthouse-core/lib/tracehouse. It's dependencyless and I mean how frequently do we update that logic anyhow.

To be honest, given our timeframe constraints and lack of clarity on where the report UI components might go, I think I prefer the hackier alternatives, but the long-term vision of doing things the right way does get me all warm and fuzzy, so feedback welcome! :)