kita-html check
Estimated reading time: 3 minuteskita-html check finds unsafe JSX with the TypeScript 7.1 type checker. It reports the
same TS88601 to TS88604 diagnostics as the editor plugin it replaces,
and it is the recommended XSS check for Kita Html projects.
TypeScript 7 does not load language service plugins, so the check runs as a command
instead of inside the editor. Projects that still use TypeScript 6 can keep the deprecated
editor plugin and xss-scan until they upgrade.
Install
The CLI requires Node.js 22 and TypeScript 7.1 or later. TypeScript 7.1 is published under
the next tag until its stable release. The check loads the typescript package
installed in your project, so its results follow your compiler version.
Run the check
Without arguments, the command checks every TSX and JSX file of ./tsconfig.json. Pass
-p to choose another config, and repeat it to check several projects in one run. A
solution-style tsconfig.json that only lists references is expanded to every
referenced project, like tsc -b.
The command exits with 0 when nothing is found, 1 on errors or invalid configuration,
and 2 when only TS88604 warnings remain. Output formats
describes every format and exit code.
To report on some files only, such as staged files in a pre-commit hook, pass them as arguments. Types still come from the full project. Files outside the project, or files that are not TSX or JSX, are skipped with a warning.
Report in GitHub pull requests
--format github prints a GitHub Actions annotation per finding, so each finding appears
on the changed line of the pull request. Inside GitHub Actions, --format defaults to
pretty,github, which adds those annotations to the usual colored output with no extra
configuration. Paths are resolved against GITHUB_WORKSPACE, which keeps annotations
attached when the check runs from a package directory of a monorepo.
GitHub displays a limited number of annotations per step, so keep pretty or tsc next
to github to have the full list in the job log. With github selected, the pretty
headers do not match the tsc problem matcher that actions/setup-node registers, so
findings are not annotated twice.
Show findings in VS Code
--format tsc prints findings in the same format as tsc. The built-in $tsc problem
matcher of VS Code parses it and lists each finding in the Problems panel, linked to its
source line.
Run the task from Terminal > Run Task. Other editors and CI tools that parse tsc
output accept the same format.