EditorConfig Generator

What this tool does

This tool builds an .editorconfig file from a few choices: indent style and size, line endings, character set, trailing-whitespace trimming, a final newline, an optional maximum line length, and a set of ready-made overrides for languages that need an exception to the global rules. It outputs plain text you can drop in the root of a repository.

When you need it

• Starting a project and wanting editors to agree on indentation and line endings from the first commit.
• Stopping whitespace-only diffs caused by teammates on different editors or operating systems.
• Adding the exceptions that always bite: Makefiles need tabs, Go uses tabs, YAML forbids them, Markdown depends on trailing spaces.
• Checking what a property is called, or what a value should look like.

What the generated file means

The file starts with root = true, then a [*] section applying to every file. The properties come from the EditorConfig specification at editorconfig.org: indent_style (space or tab), indent_size, tab_width, end_of_line (lf, crlf or cr), charset (utf-8, utf-8-bom, latin1, utf-16be, utf-16le), trim_trailing_whitespace and insert_final_newline. When the style is tab, the tool writes tab_width rather than indent_size; with indent_style = tab and no indent_size, a conforming editor uses tab_width for the indent size. max_line_length is only written if you set a value above zero, and note that support for it varies between editors.

Precedence rules

This is where most confusion comes from, so here is what editorconfig.org specifies:

1. Editors search for .editorconfig files starting in the opened file's directory and moving up through each parent, and stop at the first file that has root = true in its preamble, or at the filesystem root.
2. Files closer to the opened file take precedence over files farther away.
3. Within a file, sections are read from top to bottom and later sections override earlier ones for any property they both set.
4. Section names are globs. * matches any string except a path separator, ** matches any string, ? any single character, {a,b} either alternative, and a pattern with no slash matches a file name at any depth.
5. A property set to unset removes the value inherited from earlier matches.

Rule 3 is why the generator always writes [*] first and the language overrides after it: an override placed above the global section would be silently overwritten. The generated files were checked against the reference Python EditorConfig parser: with the default settings README.md resolves trim_trailing_whitespace = false and a Makefile resolves indent_style = tab; with the shell override on, .sh files resolve end_of_line = lf even when the global setting is CRLF; and a file that sets indent_style = tab with only tab_width resolves indent_size to the same number.

The overrides, and why

• Markdown: trim_trailing_whitespace = false. Two trailing spaces mean a hard line break in Markdown, and trimming them silently changes the rendered document.
• Makefile: indent_style = tab. Make requires a tab before recipe lines. Note that the global indent_size still applies to the width a tab is shown at, unless you also set tab_width.
• Go: tabs, because gofmt uses them.
• Python: four spaces, per PEP 8.
• YAML: spaces only, two wide, because the YAML specification forbids tabs for indentation.
• Shell: LF endings. A CRLF in a shebang line makes Linux look for an interpreter named bash plus a carriage return and fail with "bad interpreter".
• Windows scripts: .bat and .cmd use CRLF.

What .editorconfig does not do

It configures editors; it does not reformat existing files, fail builds, or override a formatter such as Prettier or gofmt that rewrites your code. Editor support is native in some editors and a plugin in others. Pair it with a formatter or CI check if you need enforcement, and keep the two in agreement so they do not fight.