Comments (41)
from prettier.
I call BS on JavaScript using 2 spaces for indentation. I've read many code bases and there's a large variety of indentation styles out there. And not only with what they use to indent, but where they indent, and where they add extra whitespace between keywords. The language itself is so dynamic and used in such different ways that expecting there to be a "standard" style is a little near-sighted. I'll concede that most people use spaces (at least from the ones that vote on surveys) But between those there are splits between the number of spaces that they use. So even if it's a majority, that doesn't necessarily mean that the majority use two spaces.
from prettier.
I think what's best about this project is that it's opinionated but still roughly adhere to conventions in the JavaScript community.
The thing is JavaScript uses 2 spaces. Other languages, like Go, use tabs.
TypeScript uses 4 spaces.
General purpose languages, like Java and C++, use all sorts of indentation.
Maybe it's because JavaScript is gradually becoming a general purpose language, we see this departure from convention.
from prettier.
Actually, tabs make this whole project pretty hard. The whole point is that we can let the user specify a maximum line length, like 80, and wrap code there. We need to know how many spaces a tab takes up so we can accurately measure code.
Need to think about this a little more.
from prettier.
Just remove --tab-width completely?
Why?
- Minimize options.
- print-width should be enough.
- Output is pipable through an end-spaces-vs-tabs-discussion-utlity.
- Editors/viewers should "fix" indentation using .editorconfig & co.
- Deep nesting π€’
README states... opinionated π
from prettier.
+1 for tabs. "Opinionated" or not, forcing users into using spaces is a really, really stupid decision.
The whole point is that we can let the user specify a maximum line length, like 80, and wrap code there.
From what I gather, this project's point is to programmatically enforce a project's coding style in a foolproof fashion. Or are you judging readability purely on line-length?
Actually, tabs make this whole project pretty hard.
How? Here's how I do it, and it's piss-easy:
- Tabs to indent, spaces to align
- Keep the two separate using non-whitespace characters, making an obvious exception for JSDoc
- Avoid using tabs as an alignment device - if the indentation depth jumps by an unexpected amount, it indicates misuse. I've published a junk project to illustrate an example.
2 spaces for indentation is the default because that's what the majority of the community uses.
This is why I hate people. I wish more people would do as @suchipi does and not assume every reader's preferred indentation width matches their own.
Anyway, I'm not posting here to start a fight - I don't want anything to do with the JavaScript community, and that includes bikeshedding. But if implementation is difficult, maybe the way I handle tabs can point you in the right direction.
from prettier.
Support for tabs in Prettier
has been merged in #1026 π
from prettier.
Am I the only person who renders tabs as two spaces? π
from prettier.
The Linux kernel (and many Linux projects, like GNOME) define tabs to be 8 characters wide; this is also the default for e.g. vim. So there's not universal consensus on 4.
from prettier.
Actually, tabs make this whole project pretty hard. The whole point is that we can let the user specify a maximum line length, like 80, and wrap code there. We need to know how many spaces a tab takes up so we can accurately measure code.
About this, I think it would be easier to add another option (indentWithTabs or something) and keep the tabWidth option, this way you would calculate the line size normally just like spaces but output tabs.
from prettier.
Finally, a formatter that doesn't support tabs, is useless for all projects or teams that use tabs. I could see how having more configuration options for stuff like "put a space after function
" would be redundant, but something as fundamental as all the indentation in a project seems worthy of having a flag. Especially given how heated the debate is on this particular topic.
from prettier.
I might not support editorconfig unless you intend to support every potentially applicable editorconfig option. Partial support for the core default options confuses users.
@jlongster That said, supporting tabs is important. Spaces vs tabs is one of those timeless holy-wars; choosing a single side will just alienate a large portion of your potential userbase.
from prettier.
As well, there's no guarantee that they can format back if the project isn't using this particular formatter
If the project isn't using this formatter, then you can you never use this formatter on that project. Once you make changes, how are you going to format it back? You can't format code on a project that doesn't use this because you'll have a lot of various styling changes. It doesn't make sense to use this formatter at all if a project isn't using it.
Since you don't want to add a new configuration option, why doesn't you make "tabs" the default indentation method?
Spaces are by far the standard in the JavaScript world. I very rarely come across a project that uses them. 2 spaces for indentation is the default because that's what the majority of the community uses.
Just like standard
we are going to choose some options for you, sorry (keeping what we think is the most used options in mind). In the future we will see if it's worth making it configurable, but as said above, it's a lot easier to add options later than to remove them. Right now we are focusing on making sure we always output valid JS code.
That may mean you can't use this project right now. There are other formatters and hopefully you can find one that works for you!
I'm closing this for now because we aren't going to work on it. That doesn't mean we'll never do it, but let's give this project a little time to settle and then I'm going to revisit the tabs and semicolon debate.
from prettier.
While all this discussion is interesting - why don't just let people decide how they want their project to be formatted? To use or not to use is simply endless topic.
from prettier.
from prettier.
If you use post-processing for tab conversion (or semicolon removal), you actually have to parse the JS again since template strings and JSX can be multiline and should not be touched. So that means a fairly significant slowdown.
I agree with #34 (comment) - it's ok for tabs to be considered e.g. 4 spaces and then when I use a different setting, it doesn't matter that the right margin fluctuates a little. Just keeping the --tab-width
setting for that seems fine.
@wiredearp Using editorconfig
actually increases complexity, no? I mean, inferring config from it seems ok, but using it as the sole source makes its use complexβ¦
from prettier.
@rhengles I'm not a fan of forks here:
from prettier.
@nschubach yes, that is one of the many advantages extolled in the article, but for prettier it matters because that changes whether to convert something to multiline or not. So by keeping the tabWidth
setting and having a useTabs
boolean, that can be configured.
from prettier.
@jlongster Formatting an entire file to have a different tab width is a practice that's just begging for somebody to forget to revert the formatting back and commit their changes. As well, there's no guarantee that they can format back if the project isn't using this particular formatter (which they likely won't given the sheer number of them out there).
from prettier.
I'm open to this, particularly because we have the --tab-width
option and we can probably repurpose that. My goal is to have no more than ~5 options or so, but this one could be good. We could make --tab-width
take an option like --tab-width tabs
or something so that it just prints tabs.
from prettier.
I usually view code at 4 space indentation, but on smaller screens I've rolled with 3 or 2 spaces per indentation.
Then again, I'm also not very dogmatic on max line width. If I'm on a giant monitor I'll let the occasional line stretch long, and I'll leave it that way until I go read/edit it on a smaller screen.
:-x
from prettier.
I second the idea of just assuming the most common setting of 4 characters-part-tab and having the actual size fluctuate if somebody has a custom setting. I doubt it would make too much of a difference either way.
Alternately, maybe tabWidth
can be set to a negative number which represents hard tabs that are going to be rendered with -N
spaces.
from prettier.
I like @wmertens suggestion, because it only adds one additional config value, is compatible with the current config. So would a PR with this addition be accepted, or is more discussion needed before someone starts tackling this?
from prettier.
@danielbuechele Not yet. I want to focus on making it completely stable with all JS constructs first before evaluating any more config options. "Only one additional config value" is always famous last words. It's way easier to add something later than it is to remove.
I'm seeing the value of tabs less when you can simply reformat a file with your preferred --tab-width
and format it back. We want to make tooling that makes this super easy, so you can view any file from any project in your preferred settings and then simply format it back. In my opinion this removes the major advantage pitched for tabs.
from prettier.
Ping @ALL! Please take a look on #908 and #920!
from prettier.
Output is pipable through an end-spaces-vs-tabs-discussion-utlity
I like this idea, but it only holds if authors don't mix spaces-for-indentation with spaces-for-alignment. If prettier
trims spaces-for-alignment, then this would be fine.
Editors/viewers should "fix" indentation using .editorconfig & co.
This is only accurate if the file is indented with tabs. If the file is indented with spaces, editors don't generally offer any way to customize indentation display. Some do offer "convert to tabs", but that would get undone by prettier
the next time it was run.
from prettier.
@jlongster Since you don't want to add a new configuration option, why doesn't you make "tabs" the default indentation method? They are the logical and specific characters to indent text, spaces are meant to separate words. This way, users who prefer spaces would:
simply reformat a file with your preferred
--tab-width
and format it back.
Maybe, you could do without even the --tab-width
option and use a fixed size of 4, for example, to calculate the total length of a line. Since it would not be a big difference anyway.
You already have an option to specify the width of the tab, which some people care about, but you don't have an option to use tabs, which a far greater amount of people care about.
from prettier.
I think hard tabs = tab characters. I had a problem with my eslint config.
Changed this:
"rules": {
"indent": [0, "tab", { "SwitchCase": 1 }],
//...
}
To this:
"rules": {
"indent": [2, "tab", { "SwitchCase": 1 }],
//...
}
That fixed my problem.
from prettier.
I'd be willing to bet that ~90% of all editors are set to show tabs are 4 characters wide. A quick couple of searches didn't turn up any formal analysis though.
from prettier.
If it must convert tabs to spaces, it suggest it should also do that within (JSDoc style) comments which now look like this:
/**
* INDENTED WITH TABS (probably because comments are simply passed through)
* @param {String} key
* @param {function} base
* @returns {function}
*/
function getter(key, base) {
return function() {
console.log(key);
return base.apply(this);
};
}
πββοΈ To minimize the amount of configuration related to supporting tabs, perhaps the relevant properties could be reduced to one setting editorconfig
that points to an external file called .editorconfig
as detailed on http://editorconfig.org/. This has bonus advantages:
- Most code editors can be rigged with a plugin that automatically configures editors settings to conform (eg. to use spaces instead of tabs and set the tab-width to
2
and so on) so that anyone on the team will automatically adopt the settings. - The
.editorconfig
file can be placed in the root of a GitHub project to control the tab-width that users will see when they browse the repository. The browsers default width is8
and this probably explains why many developers prefer spaces to tabs, but with this trick you can reduce it down to4
or whatever you prefer.
In other words, your code editor and your GitHub repo and your Prettier command line tool would all consume the same settings with regards to tabs (or spaces), tab-widths and potentially also newlines.
from prettier.
Actually, tabs make this whole project pretty hard. The whole point is that we can let the user specify a maximum line length, like 80, and wrap code there. We need to know how many spaces a tab takes up so we can accurately measure code.
About this, I think it would be easier to add another option (indentWithTabs or something) and keep the tabWidth option, this way you would calculate the line size normally just like spaces but output tabs.
Yup, This is how Sublime Text handles that:
// The number of spaces a tab is considered equal to
"tab_size": 4,
// If translate_tabs_to_spaces is true, use_tab_stops will make tab and
// backspace insert/delete up to the next tabstop
"use_tab_stops": true,
from prettier.
I switch between 4 and 2. :D
from prettier.
Thank you, and I understand your reasons. Just for reference for anyone interested, I already made a fork with this option, in the simplest way possible, without any new tests yet:
https://github.com/arijs/prettier-with-tabs
It works, but 5 of the 377 tests suites and 6 of the 1071 snapshots have broken, because of lines that were expanded and now are collapsed in a single line, and I don't know why, since adding this option shouldn't modify the default behaviour.
UPDATE: Solved it now, all tests pass. π
from prettier.
@rhengles Cool, thanks. Please keep in mind that I think we should just think about it later, so I'm postponing the decision, not denying it. We could potentially even detect if the current file uses tabs. We're trying to stay really focused right now on the bigger bugs where we don't output correct JS though.
from prettier.
@timpler that discussion has been had at length at #40.
from prettier.
@timpler My fork aims to do just that - enable anyone to add whatever configuration option they'd like.
from prettier.
@timpler You're entitled to your opinion, but as far as I'm aware, we're still at 2
and not at 15
.
That is why I didn't simply switch the indentation from spaces to tabs - I made everything configurable.
from prettier.
@rhengles are you going to maintain such fork to be up to date with prettier releases?
from prettier.
@timpler I have been doing just that since I created it. And it is really really easy.
from prettier.
Is it possible to use hard tabs?
from prettier.
@savovs what do you mean? Prettier supports spaces and tab characters, what are hard tabs for you?
from prettier.
Related Issues (20)
- 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
- Bug: functions in MDX are not formatted if there is at least one empty line HOT 2
- cli
- Github Actions for Node.js 14 x MacOS fails HOT 5
- "sanity timeout expired: Interrupted system call" on WSL2.
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.