svelte-check-reporter

See Svelte and TypeScript errors where you review code: in GitHub pull requests and GitLab merge requests.

Pipe svelte-check into your existing CI to get annotations and native reports. No runtime dependencies.

• See new and fixed findings in GitLab, and newly introduced alerts in GitHub code scanning.
• See existing GitLab findings stay matched when lines above them change.
• See errors and warnings at their original severity, with the check failing on errors and passing on warnings alone.

Demos: GitHub annotations · GitHub code scanning · GitLab Code Quality

Install alongside your existing svelte-check dependency:

npm install --save-dev svelte-check-reporter

Add one pipe to your check command:

# GitHub Actions annotations
npx svelte-check --output machine-verbose | npx svelte-check-reporter --format github

# GitLab Code Quality
npx svelte-check --output machine-verbose | npx svelte-check-reporter --output-file gl-codequality.json

For GitHub code scanning, follow the SARIF setup.

The reporter reads svelte-check's machine-verbose output and converts each diagnostic. It handles .svelte and .ts files, keeps errors and warnings distinct, and prints every diagnostic to the job log.

Requires Node.js 18.3 or later. Run from the repository root so file paths match your repository. For SvelteKit projects, run npx svelte-kit sync before the check.

Use the format your CI displays natively:

On GitHub, start with annotations for the least setup. Choose code scanning to track alerts across runs and focus reviews on new findings. Use one of the two to avoid reporting the same diagnostics through both integrations.

Show which findings a merge request introduces and which it fixes, alongside reports from your other Code Quality tools.

See the results in the demo merge request !1.

The Reports tab lists new and fixed findings:

In the Changes view, reviewers can open a finding directly from its marker in the diff:

Add this job to .gitlab-ci.yml:

check:
  image: node:24-alpine
  script:
    - npm ci
    - npx svelte-kit sync
    - npx svelte-check --output machine-verbose | npx svelte-check-reporter --output-file gl-codequality.json
  artifacts:
    when: always
    reports:
      codequality: gl-codequality.json

Remove the svelte-kit sync step if your project doesn't use SvelteKit.

The job must also run on the merge request's target branch, usually main. GitLab uses that branch's report as the baseline for identifying new and fixed findings.

Keep when: always: the report must reach GitLab even when the check finds errors.

GitLab combines Code Quality reports from multiple jobs. To distinguish svelte-check's messages from other tools, add --prefix '[svelte-check] ' to the reporter command.

Annotate errors and warnings on your workflow run and pull request diff, as shown in the opening screenshot. No additional action, personal access token or annotation permissions required.

See the annotations in demo pull request #1.

Save this workflow as .github/workflows/check.yml:

name: Svelte check

on: [pull_request]

permissions:
  contents: read

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npx svelte-kit sync
      - run: npx svelte-check --output machine-verbose | npx svelte-check-reporter --format github

Remove the svelte-kit sync step if your project doesn't use SvelteKit. To annotate pushes too, use on: [push, pull_request].

Annotations include existing findings: GitHub doesn't compare this format with the base branch. GitHub displays at most 10 error and 10 warning annotations per step. Every diagnostic remains in the job log, including those beyond the annotation limit.

Track alerts across runs and show newly introduced findings on the pull request diff, including in .svelte files.

See the alerts in demo pull request #2.

Rules use their diagnostic codes, such as TS2322 or state_referenced_locally. Svelte compiler rules link to their documentation.

Save this workflow as .github/workflows/check.yml, using it instead of the annotations workflow:

name: Svelte check

on:
  push:
    branches: [main]
  pull_request:

jobs:
  check:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
      actions: read # Required for private repositories
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npx svelte-kit sync
      - run: npx svelte-check --output machine-verbose | npx svelte-check-reporter --format sarif --output-file svelte-check.sarif
      - uses: github/codeql-action/upload-sarif@v4
        if: ${{ !cancelled() }}
        with:
          sarif_file: svelte-check.sarif
          category: svelte-check

Remove the svelte-kit sync step if your project doesn't use SvelteKit. Replace main with your target branch if it has a different name.

The workflow also analyzes the target branch so GitHub can identify new findings. security-events: write permits the upload, and if: ${{ !cancelled() }} uploads the report even when the check finds errors.

Every format preserves the diagnostic's severity:

The job log includes each diagnostic and a summary:

src/lib/db.ts:29:24  error  Property 'topology' does not exist on type 'MongoClient'.  TS2339

1 error, 0 warnings

Errors fail the command. Warnings alone don't. The reporter's exit code decides the job's result, so svelte-check's --fail-on-warnings has no effect through the pipe.

If svelte-check crashes before completing, the reporter fails rather than producing an empty report that looks clean.

The reporter reads from standard input. Use these options to choose its output:

The reporter reads svelte-check's output without importing Svelte or SvelteKit:

Prioritize GitHub annotations for files changed by the pull request, so the available annotation slots go to those files first.

MIT