Checker¶
Runs a named check across a set of files and aggregates the results; used internally by the CLI (CLI).
Runs a named check (from the checks registry) across a set of files and
aggregates the results into a single CheckResult.
- class markdown_checker.checker.CheckResult(issues=<factory>, links_checked=0)¶
Bases:
objectResult of running a check on one or more files.
- markdown_checker.checker.detect_issues(func, file_path, config, service=None)¶
Detect issues in a single markdown file using the named check.
- Parameters:
func (str) – Name of the check to run (must be a key in REGISTRY).
file_path (Path) – Path to the markdown file to check.
config (Config) – Runtime configuration for the check.
service (URLCheckService | None) – Optional shared URL-checking pipeline, reused across files in a run so duplicate URLs are only checked once.
- Returns:
A tuple of (detected_issues, links_checked_count).
- Raises:
ValueError – If func is not a registered check name.
- Return type:
- markdown_checker.checker.run_check_on_files(func, files_paths, config, progress_callback)¶
Run a named check across multiple files.
Files are processed through an adaptive window: a file’s check is submitted (but not necessarily collected) as soon as it’s reached, so link extraction for upcoming files overlaps with the network wait of files already submitted. The window drains early once roughly
2 * config.max_workerslinks are in flight - enough to keep every worker fed without link-dense files ballooning memory - but never before_MIN_FILE_WINDOWfiles, so link-sparse files still get real overlap;_MAX_FILE_WINDOWis an absolute cap either way.progress_callbackfires as each file is submitted rather than once its results are collected, so the bar advances smoothly instead of lagging behind in bursts.- Parameters:
- Returns:
A CheckResult with per-file issues and total links checked.
- Return type: