EditorConfig
When working in a team, it is a good practice to make sure your code style is consistent across your team. Often it is not as important what your specific rules are as much as that everybody sticks with the same conventions. This makes your codebase much cleaner, easier to read, and maintain.
There are various approaches to this. One popular tool is Prettier. It is an opinionated code formatter, which can reformat your code to match certain rules. You can then run it directly in your IDE, as a part of CI or before each commit using Git Hooks.
Another popular and widespread tool is EditorConfig. The approach is slightly different from Prettier. You create .editorconfig file directly in your project with your desired settings. Your IDE then detects this file and loads its configuration. Many Editors are supported out of the box, and there are plugins for many more.
An example file can look something like this:
# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true
# Matches multiple files with brace expansion notation
# Set default charset
[*.{js,py}]
charset = utf-8
# 4 space indentation
[*.py]
indent_style = space
indent_size = 4
# Tab indentation (no size specified)
[Makefile]
indent_style = tab
# Indentation override for all JS under lib directory
[lib/**.js]
indent_style = space
indent_size = 2
# Matches the exact files either package.json or .travis.yml
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2What is useful is that you can have .editorconfig file in each directory with different settings. This can be helpful with multi-module or multi-language projects. Unfortunately, the amount of supported properties is quite limited. Mostly indentation, line endings, or character encoding.
Sharing settings in IDEA
Editor config is powerful because, unlike in your IDE, you can configure settings per each directory. Also, it is a great tool for sharing the same settings among your team members with zero setup. Since .editorconfig can be kept under version control, you can just clone a project, and you are good to go as the configuration is already included.
There is one significant limitation, though. Since the list of supported options is fairly limited, there is still a whole lot of settings not covered by EditorConfig. Each IDE has a huge list of its own config properties, which cannot be shared with EditorConfig.
Traditionally, if you wanted to share these, it would involve tedious exporting and importing for each team member. Fortunately, IDEA offers several different options on how to synchronize IDE Settings.
IntelliJ IDEA Tips: Synchronization and Sharing of Settings
Jan 24, 2018
It is powerful and handy, but it is not a zero-setup approach as with Editor Config. You need to make sure each person sets up their synchronization.
Extended EditorConfig Support in IDEA
IDEA supports EditorConfig out of the box for quite some time. However, since version 2019.2 it offers extended support which also covers IDEA-specific settings, which are not part of the core EditorConfig spec.
This way, you can have both zero-setup configuration per folder and sharing of IDEA specific settings. How does it work?
Creating .editorconfig file
First, you need to create a .editorconfig file inside your project. You can do it in the same way as with any other file. Just right-click your desired directory and select:
New → EditorConfig FileBefore the file is created, IDEA shows the following dialog where you can customize its contents.
Root file
The first checkbox root=true allows you to mark your config file as a root file. What does it mean?
You can have multiple config files in your project, each in a different directory. Whenever you open a file in your IDE, it checks whether there is also .editorconfig file located in the same directory. If not, it goes up through the directory structure to search for one. It does not stop until it finds a .editorconfig file, which contains root=true. Your topmost config file should always contain root=true.
This means it can locate and load multiple config files during its search. Config from all the files found is applied. Files deeper in the hierarchy take priority over these higher in the hierarchy. This means a deeper file can extend and override whatever is in the files above.
Property sets
Now it is time to select what configuration properties should be included in your new file.
You can select standard core properties, which are supported with every EditorConfig compliant IDE by checking EditorConfig standard. However, you can also check IDEA-specific config properties for various languages supported by IDEA, such as Java, Kotlin, or HTML.
Let's try Java. Contents of the file should now contain a whole bunch of IDEA/Java-specific settings. Almost 250 new settings!
[*.java]
ij_java_align_consecutive_assignments = false
ij_java_align_consecutive_variable_declarations = false
ij_java_align_group_field_declarations = false
ij_java_align_multiline_annotation_parameters = false
ij_java_align_multiline_array_initializer_expression = false
ij_java_align_multiline_assignment = false
ij_java_align_multiline_binary_operation = false
ij_java_align_multiline_chained_methods = false
ij_java_align_multiline_extends_list = false
ij_java_align_multiline_for = true
ij_java_align_multiline_method_parentheses = false
ij_java_align_multiline_parameters = true
ij_java_align_multiline_parameters_in_calls = false
ij_java_align_multiline_parenthesized_expression = false
ij_java_align_multiline_resources = true
ij_java_align_multiline_ternary_operation = false
ij_java_align_multiline_throws_list = false
ij_java_align_subsequent_simple_methods = false
ij_java_align_throws_keyword = false
ij_java_annotation_parameter_wrap = off
ij_java_array_initializer_new_line_after_left_brace = falseAnd many more. Notice that each of these lines has a prefix of ij_. This way, you can easily distinguish regular settings from IDEA-specific ones.
Insert as comments
IDEA supports a lot of different configuration options, nearly 250 just for Java. Instead of inserting all you may prefer hand-picking just some of them.
You can select Add properties as comments. This way, all the supported properties are inserted commented-out. You still can see all the supported options, but you can uncomment just the ones you want to be applied.
Preview Mode
When tinkering with various configuration options, it is useful to check how are these reflected in a real code file. Fortunately, this is easy.
Next to each configuration section such as [Java] or [*], you can see a small eye icon.
When you click it, you can select a file, which will be used to preview your changes. Whenever you make changes to the config file, it will be reflected in your preview file.
Note that all these changes are preview-only and will not change the contents of your file.
Overrides visualization
In each .editorconfig, declared properties are evaluated from top to bottom. Which means that if you declare some property below the same property, which is already declared above, it will take priority.
For example, you can have settings for all files [*] on the top of your config file and then section for Java files only [*.java], which overrides some of the general config properties. In such case, IDEA offers you a nice visualization with icons in the gutter area. Similar to the case when you override methods from a parent class.
`
A tooltip offers an explanation of what section is overriding or overridden. By clicking the icon, you can navigate to that section. This works both inside one file as well as across the whole hierarchy.
Settings priority
As described above, you can have multiple .editorconfig files. This can be useful for having different settings for different packages or modules. Or to have different settings for production and test code. Or for different languages. To sum it up:
- The settings from one config file are applied to all its subdirectories.
- If there is a different setting in a subdirectory, it takes priority over settings from parent directories
- Topmost config file must have
root=true - Editor config settings have priority over your IDE settings
- If a setting is not found in
.editorconfig, it is taken from your IDE settings
Syncing plugins
While extended EditorConfig support is very powerful, it is not a full-fledged replacement for good old IDE Settings synchronization, which can also sync your IDE plugins and various other IDE settings.
Conclusion
EditorConfig in IDEA just got way more powerful. It does not support only original EditorConfig options, but a whole lot of IDEA-specific options as well. This way, you can easily share unified IDE configuration among your team members with zero-setup. No more import/export of settings or tedious setup of IDE Settings Sync. Moreover, you can now have different configuration options for each directory separately.
