.editorconfig Generator

One file, consistent formatting

An .editorconfig file tells editors how to format files in a project: indent style, indent size, line endings, character set, and whether to trim trailing whitespace. Most editors read it natively or through a plugin, so a team on mixed tools still produces the same whitespace. It settles the tabs-versus-spaces argument once, at the repo level.

How the rules apply

The file is read from the current directory upward until one with root = true is found. Sections use glob patterns, so you can set a default under [*] and then override specific file types. This is how a project uses two-space indentation everywhere but tabs in Makefiles, which require them.

Example

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

[Makefile]
indent_style = tab

Markdown keeps its trailing whitespace because two trailing spaces mean a hard line break there, and the Makefile section restores the tabs its syntax demands.

Pitfalls

EditorConfig only governs whitespace and encoding; it does not reorder imports or enforce code style, so it complements a formatter like Prettier rather than replacing it. Forgetting root = true lets a parent config leak in unexpectedly. Pair it with a .gitignore generator to round out a repo's baseline config.

FAQ

Does every editor support it? Many do out of the box; others need a plugin. Unsupported editors simply ignore the file, causing no harm.

Will it fight my formatter? Keep the indentation settings in sync. If Prettier says two spaces, set the same here so they agree.

What is insert_final_newline for? It ensures files end with a newline, which avoids noisy "no newline at end of file" diffs in version control.