How do I generate an ESLint HTML report?

`npx eslint . -f html -o eslint-report.html`. The html formatter writes one self-contained file with its CSS inlined, grouped by file, with the rule id on every row.

Publish the file — one curl, or drag it into the app — and send the URL. It's a single file, so nothing about it needs an assets folder or a local web server.

Why not just paste the terminal output?

Because a lint run on a legacy codebase is thousands of lines and the interesting part is the distribution — which rules, which directories, which of them are worth fixing versus disabling. That's a question about a report, not about a scroll buffer.

How do I track the count going down?

PATCH the same report id on every run. The URL stays stable and each run appends a revision, so a cleanup effort has a visible slope instead of a number somebody quotes from memory.

Can the team argue about a specific rule in place?

Yes — that's usually the actual work. Threads anchor to the rendered content, so 'we should turn this one off' sits on the rule's rows rather than in a design-doc comment.

Share an ESLint HTML report

ESLint ships an HTML formatter that almost nobody uses, because the report has nowhere to go:

npx eslint . -f html -o eslint-report.html

One self-contained file: grouped by file, rule id on every row, severity colour-coded. No assets folder, no local server needed — which makes it the easiest artifact in this whole category to publish.

Publish it

curl -X POST https://commareports.com/api/v1/reports \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html eslint-report.html \
        '{title: "Lint — main", html: $html, visibility: "registered"}')"

Or drag the file into the app. Either way you get a URL that opens for anyone you share it with.

Why this is worth doing at all

A lint report on an established codebase is not a to-do list, it's an argument. Four thousand findings, and the useful conversation is about which rules earn their keep:

Which directories carry the debt.
Which rules produce most of the volume, and whether that's signal.
Which findings are the ones to fix before the next release.

That conversation happens on the report if the report is a link, and happens nowhere if it's a CI log. Anchored comments put "let's downgrade this to a warning" on the rows it's about.

From CI

npx eslint . -f html -o eslint-report.html || true   # don't lose the report on a red run

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html eslint-report.html \
        --arg title "Lint — $GITHUB_SHA" '{title: $title, html: $html}')"

PATCHing one report id keeps one URL and appends a revision per run, so a lint-cleanup sprint has a curve. See publishing from CI.

Limits

Entry HTML: 5 MB. A very large report can pass that — scope the run (eslint src/) or publish per package in a monorepo, which is the more useful report anyway.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a lint report →