Consider respecting EditorConfig file for whitespace and encoding options about prettier

[josephfrazier]

I've just added support for .editorconfig's indent_style, tab_width, and max_line_length properties to my prettier wrapper, prettier_d, if anyone's interested in trying it out. Usage looks like prettier_d --pkg-conf path/to/file.js. See the documentation for more details.

EDIT: package.json and .prettierrc files are also supported, if you're interested in more flexible per-project configuration

[garth]

I have multiple projects for different customers each with their own formatting standards. Editor config support would be amazing, at least for the settings that are currently configurable via the prettier cli and editor plugins.

[FlorianWendelborn]

@lydell .editorconfig in particular. If the repo is already configured there is no need to add custom prettier config files for a team that may not use prettier.

And honestly, I hate having config files in the root folder of a repo. They take up space in your editor/IDE, on GitHub, and in the Finder while distracting from the readme, tree-view, or real source-code.

[josephfrazier]

@lydell:

Trying to summarize, with .editorconfig you would be able to specify these options:

• --tab-width
• --use-tabs

Additionally, we could read end_of_line from there instead of using guessLineEnding(text).
But these options would have to be specified somewhere else:

• --print-width

Oh, I didn't think about end_of_line, nice! We can also convert EditorConfig's max_line_length to --print-width. See here for a list of EditorConfig properties: https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties

---

In general, I think one of the primary benefits of built-in support for EditorConfig by default is that it makes it easier for EditorConfig users to start using Prettier without having to duplicate their settings into a new file (note that some users may not even want additional Prettier config beyond what's already in .editorconfig!). I think it also makes the initial prettier experience a little friendlier, by not "screwing up my indentation".

[gautaz]

Hello,

I don't think the point of this issue is not having too many top-level dotfiles.

IMO, the point of .editorconfig is to specify a common editor configuration for all developers working on the same project.

The editor can use prettier to reformat a file at some point, but I don't think that prettier can be used by the editor each time it is opening a new line, so the editor cannot rely entirely on prettier for formatting thus the use of .editorconfig.

EditorConfig is supported by many editors and is thus widely used. Having to tell prettier in a separate file to use the same settings that I have already told my editor to use through the .editorconfig file (for tabs/spaces, indent size, ...) seems error prone.

Offering the ability to tell prettier (through its own configuration file) to also read the .editorconfig in order to read the settings that all developer's editors are already using would somehow reduce discrepancies between the editors' behavior and prettier behavior.

Hope this will help understanding the whole picture.

[lydell]

Having to tell prettier in a separate file to use the same settings that I have already told my editor to use through the .editorconfig file (for tabs/spaces, indent size, ...) seems error prone.

Play the devil’s advocate: Both .editorconfig and Prettier config are one-time set-it-and-forget-it things. Having to duplicate tabs-vs-spaces and indent size (that’s all, no “etc”!) between those two files does not seem so bad.

[lydell]

Nice! I think we've collected enough information now to prove that EditorConfig support could be useful and to keep the issue open.

[lipis]

Now that Prettier supports using their own configuration file and from package.json.. I think it's kind of natural now to support the editorconfig's settings if present.. (Just don't forget this file might contain different rules for different files.. should be smart enough.

[wiredearp]

The .editorconfig is also required for GitHub code views to render your tabs (not spaces) with any desired unit of spaces instead of the 8 that is default, so even a code base that is not shared between multiple developers may still need to define this file to look "prettier" on GitHub.

[gautaz]

Play the devil’s advocate: Both .editorconfig and Prettier config are one-time set-it-and-forget-it things

That's the point, as a user, I do not want to forget it each time I set up a new project and I do not want to repeat myself.

From my point of view, tools should be inclusive and behave well with each others. The more inclusive they are, the more chance they will be embraced by users.

The fact that prettier is able to take settings already configured in a project somewhere would make it more compelling for users.

Nevertheless I can understand that, as a prettier contributor, one do not want prettier to be dependent on another tool's configuration format. So there is probably room for a plugin system able to fill the gap between prettier and EditorConfig.

Users would issue something like npm install prettier prettier-editorconfig instead of installing prettier alone.

This probably just needs to be discussed to find the right solution pleasing both sides, users and contributors.

[azz]

@dodekeract If the only issue is too many top-level dotfiles, you can move it to a ./config directory and pass --config ./config/.prettierrc.

[vramana]

Support for Tab characters has been asked here #34.

[lydell]

Prettier 1.6+ has support for configuration files. Are people who have 👍:ed this issue looking for any kind of configuration file (which now exists), or looking for .editorconfig support in particular?

[josephfrazier]

Yeah, I think it would be great if Prettier respected .editorconfig (overridden by prettier config, of course). I think I've got a WIP branch laying around for this, so I might to try clean it up and open a PR.

[lydell]

Trying to summarize, with .editorconfig you would be able to specify these options:

• --tab-width
• --use-tabs

Additionally, we could read end_of_line from there instead of using guessLineEnding(text).

But these options would have to be specified somewhere else:

• --print-width
• --no-semi
• --single-quote
• --no-bracket-spacing
• --jsx-bracket-same-line
• --trailing-comma

So is .editorconfig support really worth it? Or am I missing something? :)

[azz]

So there is probably room for a plugin system able to fill the gap between prettier and EditorConfig.

You wouldn't even need a plugin system. Just an executable JS file that reads editorconfig and calls prettier with --use-tabs or --tab-width, and forwards the rest of the arguments.

[gautaz]

Just an executable JS file that reads editorconfig and calls prettier with --use-tabs or --tab-width, and forwards the rest of the arguments.

So instead of calling directly prettier, the editor would call this executable JS file. Yes, that would work as long as prettier favors its command line arguments over its configuration file.

As a vim user, it also means I cannot use directly vim-prettier or do I? Perhaps I could transfer the EditorConfig settings to vim-prettier by adding additional vimscript but this would work only for vim.

Using this method seems generating additional boilerplate for each editor when the user wants to use both prettier and EditorConfig.

[azz]

Yes, that would work as long as prettier favors its command line arguments over its configuration file.

This is now configurable - https://github.com/prettier/prettier#--config-precedence