# cfv checks syntax, schema and formatting across 18 config file types > Config File Validator is a Boeing open source Go toolchain that catches syntax errors, schema violations and formatting problems across a repository and fixes what it can, shipping as a single static binary with no runtime dependencies. Version 3.0.0 is the current release and it covers JSON, YAML, TOML, XML, HCL, INI, CSV, CUE, KDL and more. **Boeing/config-file-validator** — Cross-platform config file CLI toolchain. Validates syntax, schema compliance, and formatting across 18 different configuration file types. Written in Go. - Repository: https://github.com/Boeing/config-file-validator - Website: https://boeing.github.io/config-file-validator/ - Stars: 517 · Forks: 117 - Language: Go - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/boeing-config-file-validator ## One binary that checks a whole repository's config files The tool is called cfv, short for config file validator, and the README describes it as a toolchain for configuration files. It catches syntax errors, schema violations and formatting problems across your repo and fixes what it can. The distribution model is the first thing to note: a single static binary with no runtime dependencies, which in practice means it drops into a CI image without dragging a language runtime along. The repository is Go, the module path is github.com/Boeing/config-file-validator/v3, and it requires Go 1.26.9 to build. The licence is Apache 2.0. The last push was on 2026-10-19 and the release list shows v3.0.0 on 2026-09-30, preceded by two release candidates, v3.0.0-rc.3 on 2026-08-27 and v3.0.0-rc.2 on 2026-07-29, which tells you the 3.0 line went through a long candidate phase before settling. ## Three commands, and the exit code that matters The usage section is three commands. The first validates syntax, enforces schemas and checks formatting across the given path. ```shell cfv check . ``` The same command with --fix repairs formatting, trailing commas and type coercion. ```shell cfv check --fix . ``` The third is a dry run that shows you what formatting changes would look like as a diff. ```shell cfv format --diff . ``` The behaviour that matters for CI is stated in one line: the tool exits with code 1 if any file fails. That single fact is what makes it usable as a gate rather than a linter you have to parse output from, and it is also why the diff mode exists, since a contributor should be able to see what would change before it changes. ## The format table, and where the gaps are The supported formats table has three columns of capability, syntax, format and schema, and it is the honest way to see what the tool covers. The formats with all three are JSON, JSONC, YAML, TOML and XML. TOON and SARIF have syntax and schema but no formatting. HCL, INI, Properties and ENV have syntax and formatting but no schema support. HOCON, CSV, EDITORCONFIG, Justfile, KDL, CUE and Apple PList XML have syntax checking only. Those gaps are not arbitrary. Schema validation relies on JSON Schema, XSD and automatic SchemaStore lookup, and those three cover the formats that have a schema ecosystem, so formats like HCL and INI simply have no schema format to validate against. The formatting column depends on a formatter existing for the format, which is why the newer or less common formats, CUE and KDL among them, stop at syntax. For a team that means the tool gives you uniform syntax checking everywhere, uniform formatting for the mainstream formats, and schema enforcement where a schema exists. ## Schema validation and how formatting picks up your existing config Two integrations define how the tool behaves in a real repository. Schema validation uses JSON Schema, XSD and automatic SchemaStore lookup, so a file can be checked against a schema it does not have locally, provided one is published for that format and filename. Formatting reads your existing .prettierrc, taplo.toml, .yamlfmt and .editorconfig files, which means the tool does not impose its own house style but follows the conventions already committed to the repository. That is a significant design choice. A config linter that rewrites files in its own preferred style creates churn the first time it runs and disagreement thereafter, whereas one that honours the existing configuration files fits into a repository without a fight. The cost is that a repository with no .prettierrc and no .editorconfig gets whatever the tool's defaults are, and the formatting behaviour is then not obvious from the repository itself. ## Reporters for CI, and the GitHub and pre-commit integrations The CI section shows a check with an explicit reporter and the SchemaStore flag enabled. ```shell cfv check --reporter=junit:results.xml --schemastore . ``` The available reporters are standard, json, junit, sarif and github. The junit one produces the results.xml that most CI dashboards ingest, the sarif one produces the format that code scanning tools read, and the github reporter emits workflow commands so errors appear as inline PR annotations, which is the difference between a failing check and a comment on the diff. There is also a separate GitHub Action, validate-configs-action, and a pre-commit hook, so the same checks can run on a developer machine before anything is pushed. Running the same tool in both places is the arrangement that keeps a repository clean, since the pre-commit hook catches the change at the point where it is still cheap to fix. ## Installing it: brew, go, winget, scoop, MacPorts or a release binary Homebrew is the shortest route. ```shell brew install config-file-validator ``` If you build from source, the module path is versioned as v3. ```shell go install github.com/Boeing/config-file-validator/v3/cmd/cfv@latest ``` There are more options in a collapsed section of the README. Winget installs it with winget install Boeing.config-file-validator, Scoop with scoop install config-file-validator, MacPorts with sudo port install config-file-validator, and prebuilt binaries are on the GitHub Releases page. The Dockerfile in the repository builds a static linux-amd64 binary with CGO disabled and the netgo tag, then copies it into an alpine 3.24 image running as an unprivileged user with uid 10001. The repository also ships a PKGBUILD.template for Arch packaging and a website directory holding the documentation site published at boeing.github.io/config-file-validator. ## Where cfv is the wrong choice Three limits. The first is that the breadth is the trade. A tool that handles 18 formats with a single command necessarily handles each format less deeply than a specialist, and the table shows where that shows: formatting for JSON and YAML is driven by .prettierrc, which is Prettier's behaviour rather than a Go-native implementation, and the schema coverage stops where the schema ecosystems stop. If your repository is 90 percent YAML with a house .prettierrc, then prettier with the right plugin and a JSON Schema checker will do the same job with less machinery. The second is that formatting a config file is not always what you want. A generated file, or a file whose exact byte layout matters to another system, is one you would exclude, and the README's visible sections do not document an exclude pattern, so you would be relying on how the tool decides which files to check. The third is the interface, and this one is a real limitation. The README's usage section covers check, format and the reporters, and the documentation links point to a CLI reference for the full flag list, so the fine control lives in a separate site. For a tool you intend to enforce across a whole organisation, that means the flag set is not in the repository you are reading, and you should read the CLI reference before you decide how to configure it. ## Conclusion Adopt cfv if you want one command that checks syntax, schema and formatting across every config format in a repository, and if you want a static binary your CI can run without a language toolchain. Skip it if your configs are all one format that a dedicated linter already covers better, since the breadth is the feature. Before you wire it in, read the formatting guide, because the tool reads your existing .prettierrc, taplo.toml, .yamlfmt and .editorconfig files, and its output format depends on them. ## FAQ ### What does the cfv tool do? It is a toolchain for configuration files that catches syntax errors, schema violations and formatting problems across a repository and fixes what it can. It ships as a single static binary with no runtime dependencies, and exits with code 1 if any file fails. ### How do I install config-file-validator? With `brew install config-file-validator`, or `go install github.com/Boeing/config-file-validator/v3/cmd/cfv@latest` to build from source. Winget, Scoop, MacPorts and prebuilt binaries on the GitHub Releases page are also listed in the README. ### Which config file formats does cfv support? Eighteen formats, from JSON, JSONC, YAML, TOML and XML through HCL, INI, Properties, ENV, HOCON, CSV, EDITORCONFIG, Justfile, KDL, CUE, TOON, SARIF and Apple PList XML. Syntax checking covers all of them, formatting covers the mainstream subset, and schema validation applies where JSON Schema, XSD or SchemaStore lookup applies. ### How does cfv integrate with CI? Reporters are available in standard, json, junit, sarif and github flavours, and the github reporter emits workflow commands so errors appear as inline pull request annotations. A separate GitHub Action and a pre-commit hook are also provided, and the README shows a check with `--reporter=junit:results.xml --schemastore .`. ## Sources - [Boeing/config-file-validator on GitHub](https://github.com/Boeing/config-file-validator) - [License: Apache-2.0](https://github.com/Boeing/config-file-validator/blob/main/LICENSE) - [Project website](https://boeing.github.io/config-file-validator/) - [README](https://github.com/Boeing/config-file-validator/blob/main/README.md) - [Releases](https://github.com/Boeing/config-file-validator/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/boeing-config-file-validator