How to Generate an .editorconfig File

Tabs vs spaces. Two spaces or four. LF or CRLF. These arguments have wasted more code review time than any actual bug. An .editorconfig file settles the debate once by encoding your team’s style decisions in a file that every major editor respects automatically. The EditorConfig generator builds this file for you with the right sections for each language in your project.

Why this matters

When developers on the same team use different editors — VS Code, IntelliJ, Vim, Sublime Text — each editor applies its own default formatting. Without a shared configuration, pull requests fill up with whitespace-only diffs, line ending changes, and inconsistent indentation that obscure the actual code changes. EditorConfig solves this at the editor level, before code even reaches a linter or formatter.

The .editorconfig file uses an INI-like format with glob patterns to match file types. A root = true declaration at the top tells editors to stop searching parent directories for additional EditorConfig files. Below that, sections like [*.py] or [Makefile] define settings for specific file types. The most commonly used properties are indent_style (tab or space), indent_size, end_of_line (lf, crlf, or cr), charset, trim_trailing_whitespace, and insert_final_newline.

EditorConfig is supported natively in VS Code, IntelliJ IDEA, PyCharm, WebStorm, GitHub’s web editor, and many others. Vim, Emacs, and Sublime Text need a plugin, but installation is straightforward. Because the file lives in your repository, new team members and CI environments pick up the settings automatically.

Tips and best practices

• Always set root = true. Without this, an editor may find an .editorconfig in a parent directory and merge those settings with yours, producing unexpected results.
• Match language conventions. Use 4 spaces for Python (PEP 8), 2 spaces for YAML and JSON, and tabs for Go and Makefiles. Following community standards reduces friction for contributors.
• Set insert_final_newline = true. POSIX defines a line as text ending with a newline. Missing final newlines cause noisy diffs and can break tools that process files line by line.
• Combine with a formatter, don’t replace one. EditorConfig handles basic whitespace rules but does not enforce code style like bracket placement or import ordering. Use it alongside Prettier, Black, or gofmt for comprehensive formatting.

Common issues

• Editor ignoring the file. Make sure the file is named exactly .editorconfig (with the leading dot) and is in the project root or a parent directory of the file you are editing. Also verify that your editor has EditorConfig support enabled or the plugin installed.
• Settings not applying to certain file types. Check your glob patterns. A section like [*.js] won’t match .mjs or .jsx files. Use [*.{js,mjs,jsx}] to cover all variants.
• Conflicts with Prettier or other formatters. If your EditorConfig says 4-space indentation but Prettier is configured for 2 spaces, the formatter wins on save. Align both configurations to avoid reformatting loops.