editorconfig-checker: one .editorconfig, every file type, one CI gate

The gap EditorConfig leaves between languages

The stated problem is narrow and real. Most tools, linters for example, only test one file type and need extra configuration. This tool only needs your .editorconfig to check all files. That is the whole pitch, and it is narrower than it first appears: the checker does not format your code, it verifies that files comply with the whitespace and encoding rules that EditorConfig can express.

The implemented feature list is short and specific: end_of_line, insert_final_newline, trim_trailing_whitespace, indent_style, indent_size, max_line_length and charset. Two EditorConfig properties are explicitly unsupported, spelling_language and tab_width. Knowing that list matters, because tab_width being unsupported is the kind of detail that surprises people when a file passes the check but still looks wrong in a review.

The value comes from the files a language linter never opens. A YAML file, a shell script, a Makefile, a Dockerfile, a README and a vendored dependency are all subject to the same .editorconfig, and a rule such as insert_final_newline or trim_trailing_whitespace applies to all of them. A Python linter will not tell you that your Terraform file has trailing whitespace, and neither will the formatter for the language of the next file added to the repository. That is the class of problem this tool exists to catch.

What the checker actually inspects, and the charset caveat

There is a separate chapter in the documentation for the charset setting, and it exists because charset is the one check that cannot be done by looking at characters. The Go module list explains why: the dependencies include wlynxg/chardet for character detection and gabriel-vasile/mimetype, plus golang.org/x/text for encoding handling, and the core rule engine comes from editorconfig-core-go.

The mimetype dependency is what lets the tool distinguish a text file from a binary one before it tries to apply whitespace rules to it. Without that step, checking a PNG for trailing whitespace would be meaningless, and worse, a binary file that happens to contain a newline at the end would trigger a false report. The charset check is separate from that classification, which is why there is a dedicated -disable-charset flag to turn off only that check.

Each check also has its own disable flag, -disable-end-of-line, -disable-indent-size, -disable-indentation, -disable-insert-final-newline, -disable-max-line-length and -disable-trim-trailing-whitespace. The granularity is deliberate: a repository that has a large existing corpus of files with mixed line endings can adopt the checker one rule at a time rather than refusing it outright. That is a real adoption path, since a tool that fails CI on a thousand legacy files gets uninstalled rather than configured.

Git tracking, dry runs and the fix mode

The usage text states the default behaviour plainly: with no FILE arguments, all files tracked by git are checked, and when one or more FILE arguments are given, only those files are checked, with the configured exclude patterns still applying. Scoping to git-tracked files is a sensible default for a repository tool, since it excludes build output and anything ignored, though it does mean a file that is not yet added is not checked.

Three flags shape how it behaves in a pipeline. -dry-run shows which files would be checked, which is the flag to reach for before wiring anything into CI, since it tells you the file set without reporting violations. -fix fixes supported EditorConfig violations before checking, which turns the tool from a reporter into a writer, and that is a decision with consequences: in a CI job it can commit or modify a working tree, and on a developer machine it silently rewrites files. -init creates an initial configuration, which generates the .editorconfig-checker.json file for a repository that wants to customise the tool's own settings.

The output format is selectable with -format, offering default, codeclimate, gcc and github-actions. The github-actions format exists so a failure appears as an annotation on the offending line in the pull request rather than as a wall of text in the log, and the codeclimate format feeds a code quality report. The tool also has -config for pointing at a config file, -exclude for a regular expression of paths to skip, -ignore-defaults to turn off the built-in exclusions, -debug for troubleshooting, and -cpuprofile for writing a CPU profile to a file.

Excluding lines, blocks and paths

The exclusion system has three levels and they solve three different problems. Excluding lines and excluding blocks use EditorConfig's own syntax, where a block is a range of lines and a line exclusion is a single one, so you can carve out a region of a file that has to keep a trailing space. Excluding paths is different: it is about whole files, and it comes in inline and configured forms.

The inline form is the -exclude flag, which takes a regular expression and needs to be a valid one, with patterns combined using a pipe, for example -exclude "vendor|testdata". The configured form lives in .editorconfig-checker.json, and the repository ships a JSON schema for it at .editorconfig-checker.schema.json, which means editors can validate the file as you type it. There is also a notion of default excludes that ship with the tool, and -ignore-defaults turns them off when a project wants to check everything.

The existence of a default exclude list is worth thinking about. A tool that silently skips certain paths is convenient, and also means a file in one of those paths is never checked. For a repository where the excluded set is deliberate, such as vendor directories and test fixtures, that is correct. For a repository where someone quietly added a pattern to skip a directory that does need checking, the tool will report a clean bill of health and the mistake will not be visible in the output.

Installation paths, from Go to a container image

There are several documented ways to install it, which is a sign of how widely it is expected to run. With Go, the module path is versioned:

go install github.com/editorconfig-checker/editorconfig-checker/v4/cmd/editorconfig-checker@latest

Nix users get a package and a flake run:

nix-env -iA nixpkgs.editorconfig-checker

The container route runs the check against the current directory without installing anything locally:

docker run --rm --volume=$PWD:/check ghcr.io/editorconfig-checker/editorconfig-checker:4.0.2

Homebrew, mise, pacman and the AUR cover the common package managers:

brew install editorconfig-checker

mise use -g editorconfig-checker@latest

  pacman -S editorconfig-checker

There are also language specific wrappers, an npm package for JavaScript and TypeScript, a PyPI package for Python and a Composer package for PHP, each pointing at its own documentation for usage. The Docker image is built from an Alpine base with git installed, and the container needs git inside it to know which files are tracked, which is why the image installs git and marks the mounted directory as a safe directory.

The quickstart block downloads a pinned release tarball for a given version, operating system and architecture, unpacks it and runs the binary from a bin directory, and the Docker and quickstart versions are kept in sync with the release tags by automation markers in the documentation.

Pre-commit hooks and the CI shape

The repository ships .pre-commit-config.yaml and .pre-commit-hooks.yaml, so the natural integration point for many teams is a git hook rather than a CI job. A pre-commit hook catches the violation before the commit exists, which is a better developer experience than a failed pull request, and it also means the fix happens on a machine where the developer can see the diff.

A CI gate has the advantage of being unavoidable. The repository itself has a continuous integration workflow, and the -format github-actions option exists specifically to make the failure readable in that environment. Both can be used together, and the documentation's separate chapter on Continuous Integration is where the project's own recommended setup is described.

The build system is Go with a Makefile whose test target runs the suite twice, once with the race detector and once with -trimpath, then runs go vet and a gofmt check. The race detector is skipped when cgo is disabled and on windows/arm64, which the Makefile explains inline. Builds are produced by goreleaser, and the Docker image is assembled from the goreleaser output rather than rebuilding inside the container.

The module is versioned as v4, with a v4 suffix in the module path, so the go install command and the import path both carry the major version. The go.mod keeps the language version at go 1.26.0 with a suggested toolchain of go1.27.0, and the comment explains that the language version stays pinned to the original release of the oldstable Go version.

What the project does not check, and the licence

The boundary is set by EditorConfig itself, and it is easy to mistake the tool for a formatter. It verifies the rules you wrote. It does not know your language, it does not reformat code to a style, and it will not complain about import ordering, naming or complexity. If your team has a formatting standard that EditorConfig cannot express, this tool does nothing about it.

The two unsupported properties are worth stating plainly in a review, since they are the ones people expect to work: spelling_language and tab_width. If your .editorconfig sets a tab width, the checker ignores it.

The licence is MIT, which is the least restrictive common choice for a tool that is going to sit in a CI pipeline. The repository is not archived, and the last push was on 2026-10-15, with v4.0.2 released on 2026-09-19, v4.0.1 on 2026-09-04 and v4.0.0 on 2026-09-03. The v4 major line landed in September with two patch releases behind it, and the release notes are managed with release-please, so a CHANGELOG.md in the repository root is the place to read what changed before you bump a pinned version in CI.

Editorial conclusion

editorconfig-checker earns its place in a repository that already has a .editorconfig and a mix of file types, because it closes the gap that per-language linters leave and it can auto-fix the violations it understands. It does not fit a codebase with no EditorConfig file, a team that expects it to police indentation style across languages where the rule is already enforced by a formatter, or a project that needs semantic formatting decisions. Before adding it to CI, run it with -dry-run to see the file set it would touch, decide whether -fix should run in the pipeline or on a developer machine, and confirm the exclude patterns in .editorconfig-checker.json cover your generated and vendored directories so the first CI run does not fail on files nobody edits.

Frequently asked questions

Official sources

1. editorconfig-checker/editorconfig-checker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases