{
  "id": 18829801,
  "title": "Show svelte-check's errors in your GitLab merge requests (and GitHub pull requests)",
  "url": "https://urgent.news/2026/11/08/show-svelte-checks-errors-in-your-gitlab-merge-requests-and-github",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-08T01:09:17.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/faissalrez/show-svelte-checks-errors-in-your-gitlab-merge-requests-and-github-pull-requests-1akg"
  },
  "original_language": "en",
  "account": "If a SvelteKit project runs svelte-check in CI, the job may fail and the type errors can be found in the job log. Reviewers must open the log, scroll, and match each line back to the diff. ESLint errors, however, appear directly in the merge request because ESLint offers GitLab and GitHub formatters. svelte-check does not have this capability, and that's by design: its maintainers avoid adding output formats and prefer machine-readable output. The post explains how to convert svelte-check's output into a report that can be shown in GitLab and GitHub merge requests. With the --output machine-verbose flag, svelte-check prints one JSON diagnostic per line, including file, range, message, code, and whether it's an error or warning. GitLab uses a Code Quality report, a JSON file declared as an artifact, to display problems in a merge request. Comparing the merge request's report with the target branch's report, GitLab lists only the problems added by the merge request and those it fixes. A tricky part is the fingerprint field, which GitLab uses to differentiate new problems from existing ones. The reporter computes a hash of the file, error code, and message without the line number, preventing every error from being marked as new when a line is added. However, two identical errors in the same file would have the same fingerprint, differentiated only by their order in the file. The reporter can prefix messages to distinguish them from other tools in the widget, and this prefix is not part of the fingerprint. GitHub offers two ways to display errors on a pull request's diff: annotations and code scanning. Annotations require no additional command and can be used in any repository, but GitHub doesn't compare them with the base branch, and there's a limit of 10 error and 10 warning annotations per step. Code scanning uses a SARIF file, uploaded with the github/codeql-action/upload-sarif action, and compares each pull request with the base branch. It only comments on the problems added by the pull request and doesn't have a limit.",
  "summary": "If your SvelteKit project runs svelte-check in CI, you've probably seen this: the job fails, and the type errors are somewhere in the job log. Reviewers have to open the log, scroll, and map each line back to the diff. Meanwhile, ESLint's errors show up right in the merge request, because ESLint has formatters for GitLab and GitHub. svelte-check doesn't, and that's on purpose: its maintainers…",
  "key_points": [
    "svelte-check errors can be shown in GitLab merge requests using --output machine-verbose flag",
    "GitLab's Code Quality report highlights new problems added by the merge request",
    "GitHub offers annotations and code scanning for displaying pull request errors"
  ],
  "editors_take": "Converting machine-readable diagnostics into platform-specific reports bridges the gap between Svelte's design philosophy and the integrated developer experience required for efficient code reviews on GitLab and GitHub.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}