Closed ASH-Anthony closed 6 years ago
Continuing my thought from the slack channel
We may want to keep editor.insertSpaces
set to false for tabs after all. The esLint error for mixed tabs and spaces is NOT for having tabs and spaces in the same document, but rather for having both tabs and spaces in one indentation.
So if we set editor.insertSpaces
to true, one indentation could have 4 spaces, while another has 5, and esLint would not pick it up.
After thinking about this some more, I remembered that Visual Studio code has a setting where you can determine how many spaces a tab displays as. For that reason I'm now thinking that we should have insert spaces set to false. That way we can each determine whether we see a tab as 2 spaces or 4 based on our own preferences.
We might also want to modify our guideline about not changing the indentation we edit a file. I suggest we say that it's okay to change tabbing in a file to match standards if that's the only change in that check in. That way we can separate functional changes from formatting.
Bryan will:
Configuration to have the built-in VS compare ignore whitespace, and also how to use a 3rd party compare tool: https://blogs.msdn.microsoft.com/mitrik/2009/04/20/configure-diff-to-show-whitespace/
I have verified that in VS Code, at least, we can individually set our tab display and get a 2 or 4 space visual from the same tab characters
For tying all of this together, I think we can use the Prettier VS code extension which can format our files on save. It wraps the actual Prettier library and it has a CLI that allows for batch in-place updates of files.
I'll pull all this together to present to the team.
@ash-jeremyfield will explore settings in Prettier to overriding tab characters in markdown files.
Standards for this should go in the Contributing.md
file.
You can configure VS Code's formatter (including the VS Code's format-on-save feature) to follow Prettier's rules after installing the VS Code extension. It's important to note that there is priority with it's rules however. Prettier will treat the rules in the .editorconfig file with higher priority than in your VS Code settings. But yes, I was able to configure Prettier to format .js files to use tabs, and to replace tabs with spaces in .md files.
here are the settings i had to configure to get it to work
Something important to note about the Prettier VS Code extension is that it comes with a lot of default rules already define that you'll have to override if you don't like them.
Here's a link to the possible settings.
So if there are things you'd like to override, you'd have to define them in your settings. For example, trailing commas, or double quotes over single quotes.
Can Prettier be set to ignore double vs single quotes, since our standards say that it is up to the developer?
To my understanding, I don't think it can. Prettier is a formatter to eliminate opinions or preferences about things like double quotes/single quotes, and to just stick to one way of doing it. If I am wrong about this though, someone please correct me.
I think this will be the best way to get us all having a consistent feel to our formatting. We probably need to deliberate the format a bit more, but I still think this is the way to go. Thanks for doing that research, @ash-jeremyfield !
I agree that it would be a great way to add a consistent format to our projects. To my understanding, Prettier can also be installed into projects as a dev dependency, and then part of that installment would be some prettier config file that we could possibly share among projects. The reason for this is so that you could run a prettier command to automate formatting code in multiple files of your project, rather than relying on VS code. And the VS Code extension will also read from the prettier config that was created by the dev dependency.
Here's a link I found about setting that up for Ember projects.
Don't read the article in the link above, @ASH-Anthony. It uses the term "automagical". :joy:
The .md files in our repo have huge spaces.
my guess is somebody had weird spacing at some time and pushed with that spacing. vs code, by default, keeps their spacing and ignores your preference. i turned that off by changing
editor.detectIndentation
tofalse
test branch created to confirm this: https://github.com/ASHdevelopment/standards/tree/test-spaces. Whoever works on this should create a new branch and delete my test branch. I hope its possible to update all of them without manually searching for the existing tab instances