Consider adding an .editorconfig

[tmugford]

Something like the following, as a starting point at least.

root = true

[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
insert_final_newline = true

http://editorconfig.org/

[vinayraghu]

:+1:

[thedeerchild]

Could definitely be helpful. Want to reformat this as a PR? :)

[tmugford]

Hey @thedeerchild,

Sure, can do. There are a couple of caveats that I should mention though:

• There's no easy way to apply these settings retrospectively to all of the existing files in the project, so future commits will also contain whitespace changes as individual files are saved and updated with the settings defined in .editorconfig—at least I assume so, as that's how the Sublime Text plug-in works.
• Obviously this will only apply to those who have an EditorConfig plug-in installed, so it's not possible to enforce these settings.

I could also investigate adding some kind of linter, say grunt-lintspaces for example, which would help to mitigate the last point.

Let me know your thoughts.

[thedeerchild]

All or most of the files should already be indented with two spaces, so that part is fine. I'm not too worried about PRs coming in with spaces to trailing whitespace/newlines since those are easy to spot as trivial changes in the diff.

Adding a linter as part of the grunt process could be interesting as well, since that should fix or warn about the indentation issue before people submit their PRs (assuming they test their code, which they should be).

[tmugford]

4764 doesn't include grunt-lintspaces for a few reasons:

• I was unsure exactly which files it made sense to check (docs, js, scss, specs?)
• It doesn't fix the identified whitespace issues, and actually stops the task if it finds any problems (as opposed to just issuing a warning)

I think it's still something that could be implemented in a future PR, but it probably warrants some more careful consideration.