EditorConfig for a Multi-Language Project

EditorConfig is a cross-editor configuration standard that solves a practical team coordination problem: different developers use different editors, and those editors have different default settings for indentation, line endings, and trailing whitespace. Without EditorConfig, a developer using VS Code with spaces might open a file that a Vim user wrote with tabs, see a mass of whitespace changes in every diff, and accidentally introduce mixed indentation. EditorConfig creates a single source of truth that all editors respect. The .editorconfig file uses a simple INI-like format where glob patterns in square brackets select files and properties below apply to those files. The root = true declaration at the top tells editors to stop looking for parent .editorconfig files — without it, editors may find and apply a .editorconfig from a parent directory like your home folder. Global settings (in the [*] section): charset = utf-8 ensures all files use UTF-8 encoding. end_of_line = lf specifies Unix-style line endings, which is the cross-platform default in most professional projects (Windows developers should configure git to handle line ending conversion with git config core.autocrlf input). insert_final_newline = true adds a newline at the end of files, which is required by POSIX and expected by Unix tools like cat that behave incorrectly on files without a trailing newline. trim_trailing_whitespace = true removes invisible spaces at the end of lines that accumulate silently in most editors. Language-specific settings demonstrate EditorConfig's power: JavaScript/TypeScript/CSS/JSON files use 2-space indentation (the dominant convention in these ecosystems, enforced by Prettier and most style guides). Python files use 4-space indentation per PEP 8, the Python community's universal style guide, with an 88-character line length matching the Black formatter's default. Go files use actual tabs — this is non-negotiable in Go, where gofmt (the official formatter) enforces tab indentation. YAML files use 2 spaces. Markdown files have trim_trailing_whitespace = false because two trailing spaces create a line break in Markdown syntax. Editor support: VS Code requires the EditorConfig for VS Code extension (editorconfig.editorconfig). WebStorm and all JetBrains IDEs have built-in EditorConfig support. Vim has a plugin (editorconfig-vim). Emacs has editorconfig-emacs. Once the plugin is installed, the editor automatically applies the correct settings when opening any file in a project with a .editorconfig. EditorConfig vs Prettier vs ESLint: these three tools are complementary, not competing. EditorConfig sets editor-level defaults that apply to all files regardless of language. Prettier formats the code itself (not just indentation settings). ESLint checks JavaScript/TypeScript code quality and style. Use all three together for comprehensive code consistency. Tips: commit the .editorconfig to version control so new team members and CI environments automatically get the correct settings. Add a link to the EditorConfig documentation in your CONTRIBUTING.md so new contributors know to install the editor plugin.

Example
root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.{js,ts,jsx,tsx,json,css,scss}]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4
max_line_length = 88

[*.go]
indent_style = tab
indent_size = 4

[*.{yml,yaml}]
indent_style = space
indent_size = 2

[*.md]
trim_trailing_whitespace = false
[ open in Text Diff Checker → ]

FAQ

Do I need to install a plugin for EditorConfig in VS Code?
Yes. Install the EditorConfig for VS Code extension. Unlike IntelliJ-based editors which support it natively, VS Code requires the extension to read and apply .editorconfig rules.
Why does Markdown need trim_trailing_whitespace = false?
In Markdown, two trailing spaces at the end of a line create a line break (<br>). Removing trailing whitespace breaks this intentional formatting, so it is disabled for .md files.
What line ending should I use: LF or CRLF?
Use LF (Unix-style) for cross-platform projects. CRLF (Windows) causes noise in git diffs on non-Windows systems. Set git autocrlf = input on Windows to convert on commit.

Related Examples