chore: refactor check-config handler

[tatomyr]

What/Why/How?

Refactored config checker:

• Configuration file problems are now printed to stderr in the codeframe format for every command, regardless of the --format option.
• Commands with machine-readable output formats such as json, junit, checkstyle, and sarif now report configuration problems too, instead of hiding them.
• A configuration file that fails to load now reports "Failed to load the configuration file" instead of a message written for API descriptions.

Reference

A follow-up to #3080 (comment).

Testing

Screenshots (optional)

Check yourself

• This PR follows the contributing guide
• All new/updated code is covered by tests
• Core code changed? - Tested with other Redocly products (internal contributions only)
• New package installed? - Tested in different environments (browser/node)
• Documentation update has been considered

Security

• The security impact of the change has been considered
• Code follows company security practices and guidelines

---

Note

Medium Risk
Changes CLI output and exit behavior for all commands when configs are invalid, which can affect CI parsers that assumed config issues were omitted from machine-readable formats.

Overview
Centralizes config loading and validation in loadAndCheckConfig, wired from commandWrapper instead of the old loadConfigAndHandleErrors / handleLintConfig split in lint and miscellaneous.

Config problems are always emitted on stderr as codeframe, via formatProblems with command: 'check-config' (no --format passthrough). That means json, junit, checkstyle, and sarif runs no longer hide config issues—machine-readable primary output stays clean on stdout while config diagnostics appear separately (see updated e2e snapshot for --format=json).

Load failures now surface Failed to load the configuration file instead of API-oriented error text. Config lint errors abort with AbortFlowError rather than ConfigValidationError.

Docs and changeset note the stderr/codeframe behavior; tests move to check-config.test.ts and drop the old “skip config output for json/junit” expectations.

^{Reviewed by Cursor Bugbot for commit f58206c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[changeset-bot]

🦋 Changeset detected

Latest commit: f58206c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@redocly/cli	Patch
@redocly/openapi-core	Patch
@redocly/client-generator	Patch
@redocly/recheck	Patch
@redocly/respect-core	Patch
@redocly/reunite-integration	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	83.48% (🎯 79%)	20136 / 24120
🔵	Statements	83.1% (🎯 78%)	21758 / 26180
🔵	Functions	85.26% (🎯 82%)	3830 / 4492
🔵	Branches	75.6% (🎯 71%)	14618 / 19335

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/cli/src/wrapper.ts	87.71%	62.22%	100%	87.5%	73, 93-95, 130-134
packages/cli/src/commands/check-config.ts	77.77%	71.42%	100%	77.77%	34, 38, 59, 73
packages/cli/src/commands/lint.ts	97.67%	95.45%	100%	97.67%	70-72
packages/cli/src/utils/miscellaneous.ts	65.98%	57.6%	78.94%	65.27%	128, 185-235, 261-262, 272-273, 288, 309-342, 366, 375, 383-405, 520
packages/core/src/format/format.ts	63.11%	50%	75.67%	62.55%	25, 68-69, 115, 122-145, 163, 167, 175-189, 226-227, 236-261, 297-299, 308-347, 352, 365-371, 389, 426-432, 485-497, 511-512, 541

Generated in workflow #12258 for commit f58206c by the Vitest Coverage Report Action

[github-actions]

Performance Benchmark (Lower is Faster)

CLI Version	Bundle	Lint	Check Config
cli-latest	▓ 1.01x ± 0.01	▓ 1.00x (Fastest)	▓ 1.00x ± 0.01
cli-next	▓ 1.00x (Fastest)	▓ 1.01x ± 0.01	▓ 1.00x (Fastest)

[vadyvas]

2 questions, but generally lgtm

[vadyvas]

can we avoid type cast?

[tatomyr]

I tried, but it's still needed (same as in other command handlers). It's a different story anyway.

[vadyvas]

should this file live in /commands/?
every other command exports a handle<Command>
maybe it worth to move it to utils/, or keep it near the wrapper.ts ?

[tatomyr]

Good question. I decided to put it as a regular handler even though it doesn't get triggered by the command itself just for the sake of consistency, and to encapsulate everything related to the feature in one place.