@design-parity/report-html

中文文档
1.18.0发布于 2026/11/07Apache-2.0TypeScriptES Module构建来源已验证近 30 天下载 3736

Self-contained HTML comparison page per parity run: reference | candidate | diff side by side with the verdict findings, inlined to one offline .html file (data-URI PNGs + inline CSS/JS, no external assets).

原始使用文档
文档目录3 节
  1. Usage
  2. Branch landing page
  3. CLI

@design-parity/report-html

The per-run self-contained HTML comparison page: the rich artifact a reviewer opens from a PR to actually review a mismatch.

Given the same (DesignReference, CandidateRender, Verdict) the markdown summary uses — plus optional diff panels — renderHtmlReport emits one offline .html string:

  • reference | candidate | diff side by side per variant (paired by state/theme/size, tolerant when a side omits or relabels the size), with a vanilla opacity/overlay slider to wipe between reference and candidate.
  • the verdict findings in value order (a11y + i18n → token → semantic → visual), each with its severity, and the token expected-vs-actual shown inline from finding.detail.
  • everything inlined: CSS in a <style>, the slider JS in a <script>, and every image as a data:image/png;base64,… URI. No external requests — it opens from a file, as a CI artifact, or on GitHub Pages.

It is a leaf consumer: it depends only on @design-parity/core. The diff panels arrive as a generic DiffImage { key; png }, so it never depends on @design-parity/diff.

Output is deterministic — same input, byte-identical HTML. No timestamps, random ids, or Date.now() (docs/PRINCIPLES.md, Principle 1).

Usage

import { renderHtmlReport } from "@design-parity/report-html";

const html = renderHtmlReport({
  reference, // DesignReference
  candidate, // CandidateRender
  verdict, // Verdict
  diffImages: triptychs.map((t) => ({ key: t.key, png: t.png })), // optional
  repoRoot, // resolves reference/candidate Image.uri (defaults to cwd)
});
// write `html` to one .html file

Reference and candidate PNGs are read from disk via repoRoot + Image.uri (the same resolution the diff engine uses) and inlined. A side with no images (a semantic/token-only verdict) degrades cleanly — the findings still render.

Branch landing page

report.html is per-component; renderIndex stitches a whole run together so the published artifact branch has an entry point instead of a wall of machine-named directories. Given the run's components it returns { readme, html }:

  • README.md — what GitHub renders when you open the branch: a "generated, do not edit" banner, the source commit, an "open the board" link, and a table linking each component to its report.
  • index.html — a self-contained landing page for GitHub Pages / local view, with a small preview thumbnail of the real candidate render (reality, not the mock) next to each component, inlined as a data: URI.

Because GitHub serves a linked .html blob as source (the slider JS won't run), pass the published repoSlug + branch to wrap every report link — and the "open the board" link to index.html — through htmlpreview.github.io so they render on click without GitHub Pages; without them the links are relative (right for Pages / local view). Per-entry thumbnails come from the caller as data: URIs (orchestrate inlines the candidate's first render), keeping this package a leaf with no disk reads. Deterministic, same as renderHtmlReport.

When repoSlug + branch are set, each entry also gets a History link to GitHub's commit history for that screen's report.html. Since report.html is regenerated whenever a screen's code or mock changes, its commit log is that screen's change timeline. design-parity's publishBaseline re-parents each run on the branch tip (a linear commit chain, no force), so this works out of the box; a force-pushing publisher would flatten the branch to one commit and the link would show only the latest run.

CLI

A small demo CLI ships as design-parity-report:

design-parity-report \
  --reference fixtures/figma/button-primary.reference.json \
  --candidate fixtures/candidate/button-primary.candidate.json \
  --verdict   out/verdict.json \
  --diff default/dark/compact=out/diff-dark.png \
  --repo . \
  --out report.html

版本与发布记录

@design-parity/report-html 共发布 102 个版本,首次发布于 2026/06/14;过去 12 个月发布了 102 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
1.18.0latest2026/11/074 天前
1.17.02026/10/2617 天前
1.16.12026/10/1824 天前
1.16.02026/10/1726 天前
1.15.02026/10/1528 天前
1.14.12026/10/1230 天前

关于 @design-parity/report-html 的常见问题

@design-parity/report-html 是什么?

Self-contained HTML comparison page per parity run: reference | candidate | diff side by side with the verdict findings, inlined to one offline .html file (data-URI PNGs + inline CSS/JS, no external assets).

如何安装 @design-parity/report-html?

在项目目录运行 npm install @design-parity/report-html,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 design-parity-report,可以用 npx design-parity-report 直接运行。

@design-parity/report-html 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@design-parity/report-html 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@design-parity/report-html 可以商用吗?

@design-parity/report-html 使用 Apache-2.0 许可。宽松许可:允许商业使用、修改和再分发,并附带明确的专利授权;分发时需保留许可与 NOTICE 文件,修改过的文件要注明改动。以上为概括,不构成法律意见,请以许可原文为准。

@design-parity/report-html 的下载量有多少?

根据 npm 官方下载统计,@design-parity/report-html 在 2026/10/12 – 2026/11/10 这 30 天内被下载 3,736 次,日均约 125 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@design-parity/report-html 还在维护吗?

最新版本 1.18.0 发布于 2026/11/07(4 天前);至今共发布 102 个版本,其中过去 12 个月发布了 102 个;首次发布于 2026/06/14。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。