Comments (18)
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
from prettier.
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.
from prettier.
@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.
from prettier.
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 usingguessLineEnding(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".
from prettier.
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.
from prettier.
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.
from prettier.
Nice! I think we've collected enough information now to prove that EditorConfig support could be useful and to keep the issue open.
from prettier.
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.
from prettier.
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.
from prettier.
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.
from prettier.
@dodekeract If the only issue is too many top-level dotfiles, you can move it to a ./config directory and pass --config ./config/.prettierrc
.
from prettier.
Support for Tab characters has been asked here #34.
from prettier.
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?
from prettier.
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.
from prettier.
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? :)
from prettier.
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.
from prettier.
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
.
from prettier.
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
from prettier.
Related Issues (20)
- Ugly logical expression break in Vue `v-if`
- [bug] [yaml] list indent fix can result in invalid yaml or change the meaning of existing yaml
- HTML 'strict' whitespace sometimes injecting a '>'
- Bug with type assertion around yield expression
- Prettier breaks Markdown alert syntax
- Prettier changes meaning of HTML+JS code when using tags that look like self-closing HOT 3
- Comment in last line of YAML files gets leading newline trimmed HOT 1
- Typescript: Prettier incorrectly breaks up constructor properties from modifiers when there is a decorator and comment before it HOT 1
- [Documentation] Pre-Commit Hook Usage case caveat
- Still the error "Error: Comment "Hello" was not printed. Please report this error!" even though I have added a comment in the Doc. HOT 1
- [JavaScript] Comments between ternary operator formatting result is ugly HOT 2
- Prettier wrong formatting of Angular flow HOT 3
- Markdown undesirable formatting behaviour when new text added to paragraph HOT 2
- Error when file names HOT 4
- Can we have a CLI flag that allows ignoring .gitignore and/or .prettierignore please? HOT 2
- Unstable block comment for implemented interfaces (TypeScript) (moved and non-idempotent)
- Markdown lists with extra indent lead to unstable formatting behavior
- [SCSS] Put unary boolean operator in front of expression when wrapping HOT 3
- Incorrect JavaScript configuration caching behavior
- Omitting a key does not does not work on the Config type
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from prettier.