Diagnostic engines

Signalint invokes existing tools and normalizes their output. Enable engines in configuration and review their native configuration; Signalint does not provide an OS sandbox or reproduce every native command’s defaults.

Registered engines

Engine	Diagnostic input	How Signalint treats it	Resolution
Oxlint	JavaScript / TypeScript lint output	Requested-file batches	Optional peer, not a bundled runtime dependency; project-local preferred
TypeScript (tsc)	TypeScript compiler output	A configured program, not just the requested files	Optional peer, not a bundled runtime dependency; project-local preferred
Biome	Lint/parser output, optionally formatter output	Requested-file batches; JS/TS, JSON/JSONC, CSS, GraphQL candidates	Optional peer; local preferred, with a fallback if the peer is available beside Signalint
ESLint	Output from the project’s ESLint CLI	Requested-file batches	Project-local only; no bundled ESLint dependency

The 1.2.1 package declares optional peers oxlint@1.86.0, typescript@7.0.2, and @biomejs/biome@2.5.15; none is a required runtime dependency. Install selected engines explicitly. The resolver still has a fallback branch for Oxlint/tsc/Biome if an engine is actually resolvable beside Signalint (as in a source-development checkout). This is not a promise that a fresh published install contains those engines.

Resolution only accepts a project-local package whose canonical path is inside the selected project root. A dependency hoisted outside a package root is not automatically accepted as that package’s local engine. Use the intended repository/package root deliberately.

Missing engines

If a cache miss needs an engine that cannot be resolved, its task reports disabled with an install hint rather than inventing a clean result. All-disabled tasks lead to error / nothing_checked. An empty relevance set or cache hit can still avoid launching a missing engine.

Oxlint

init enables Oxlint when it detects a root .oxlintrc or .oxlintrc.* file, or no Biome config exists. This can enable it alongside ESLint. The list of files hashed for Oxlint is a separate, narrower list: .oxlintrc, .oxlintrc.json, and oxlint.json.

Overlapping engines can emit overlapping diagnostics. The cache is not a semantic deduplication or dependency-analysis layer.

TypeScript configuration selection

For the default check_project {} or signalint check . workflow, the first target is . and TypeScript selects the project root’s tsconfig.json.

In single-project/root-fallback mode, for check_project.paths and CLI positional paths, the first path selects one compiler configuration:

First path	Selection
Directory	That directory’s tsconfig.json; it does not fall back to the root if missing
tsconfig*.json file	That explicit configuration
Source file	Closest tsconfig.json found upward within the project boundary

Additional paths do not independently select additional TypeScript configurations. For example, check_project with paths: ["src"] can fail the TypeScript engine when src/tsconfig.json is absent, even if a root config exists.

check_files still runs the configured whole TypeScript program, then filters returned diagnostics to requested paths. Positive filteredOutIssueCount / filteredOutCount warns that other diagnostics were excluded and suggests check_project. The default compiler runner starts from .; the hash/fingerprint probe can choose the nearest config to the first requested file. The nested-config mismatch remains.

Compiler flags and artifacts

• Normal project mode uses --noEmit, --incremental, and .signalint/cache/tsc/<project-id>/tsc.tsbuildinfo.
• If effective skipLibCheck is omitted, Signalint adds --skipLibCheck in project mode. Set skipLibCheck explicitly if declaration-file checking is important to you.
• When tsc --showConfig reports a references property, Signalint uses build mode with --noEmit and --incremental.
• Build mode does not redirect build-info files to .signalint/cache/; .tsbuildinfo files can appear beside or in the configured output of referenced projects. Review the relevant ignore rules.

The --showConfig inspection cache only keys the root file’s contents. Changes to inherited configuration can leave inspection metadata cached until the process restarts.

A solution-style root with references is one way to check a monorepo. Default workspace mode is off; opt-in pnpm planning supports only its narrow discovery shapes (see monorepos), and project-snapshot limits still apply.

Biome

The documented package’s optional peer range is exactly 2.5.15:

npm install --save-dev @biomejs/biome@2.5.15

"biome": true suppresses formatter diagnostics. "biome": { "includeFormatter": true } opts in. Clear the diagnostic cache after changing this flag: v1 does not put includeFormatter in the cache key, so existing hits can retain the old behavior.

fixable is inferred from advice text matching a safe fix substring. It is not a safety guarantee or a returned patch; for example, a substring match is not a full classification of every possible advice message. Signalint does not request a fix/write mode.

If the adapter needs to run but cannot resolve Biome, it reports a disabled engine with an installation message. A cache hit or empty relevant-file set does not prove a new Biome process ran.

ESLint

Install ESLint and its required plugins in the selected project. The setup detector recognizes root flat-config filenames:

eslint.config.js    eslint.config.mjs    eslint.config.cjs
eslint.config.ts    eslint.config.mts    eslint.config.cts

The supported setup workflow targets flat config. The adapter delegates to the installed ESLint CLI rather than implementing its own legacy .eslintrc compatibility layer or forcing a particular ESLint version. File/config discovery depends on that installed CLI; nested and dynamically imported configuration is not fully represented in the cache hash.

Outcomes are not coverage certificates

Inspect engines and status. An ok outcome means the configured task resolved successfully; it may have reused cache entries or had no relevant files. It is not proof that a fresh native process checked every file.

Normal engine-task failures are isolated, preserving completed tasks’ results and setting the check status to error. Configuration loading or snapshot I/O can fail before that fan-out and may surface as an MCP request error rather than a normal check payload.

Deadlines default to 30 seconds per linter and 60 seconds for TypeScript. Termination is best-effort: POSIX process-group kills or Windows taskkill /T /F are attempted, with fallback and error logging. See security before running an untrusted project.

Source: src/engines/, src/engineResolution.ts, and src/engineFanout.ts.