adopt standard.js instead and deprecate this one

[capaj]

I have a very radical proposal-let's deprecate this guide and adopt standard.js as STRV recommended style guide. Well not that radical, since standard.js is very similar to this repo. Only difference I noticed today is:

• different rules around arrow function argument parens
• space between function () {}

The main reason for me would be compatibility with snippets-for example my favourite editor atom has https://github.com/gaboesquivel/atom-standardjs-snippets. Unfortunately not all of these snippets are compatible with the settings in this repo and that slows me down.
Another good reason would be futureproofing-there is already a big community of people behind standard making sure that it always stays up2date. For example when new language features arrive.

Thanks for your consideration, don't be afraid to vote me down if you disagree(https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments).

[robertrossmann]

There are some issues I currently see with that move:

1. Standard is all-or-nothing, while this config set gives you flexibility to gradually adopt ESLint into existing projects, making the transition more smooth
2. Not sure if standard covers all the rules, we would have to check on that. This config set does (except a few exceptions, see unused.js.
3. The ultimate vision for this coding set is to support multiple dev environments - naked browser, babel, react, node.js, you name it. The only thing stopping me from achieving that goal is my lack of experience with those environments. 😄. Not sure if we could have that with Standard.
4. Ultimately, the issue with snippets causing warnings with this coding style will be resolved once the linter plugins for various editors start supporting eslint's new --fix flag - then it will be a matter of saving the file and coding styles will be fixed automatically in most cases.

[robertrossmann]

Related: AtomLinter/linter-eslint#417

[robertrossmann]

Actually (sorry for spam!), Atom Linter already supports auto-fixing, it just does not do it automatically on save and there are no shortcuts bound to that functionality.

[capaj]

@Alaneor

1. Agree. It is debatable whether changing a codestyle from one to another is worth it. I certainly wouldn't change a project's codestyle(when some is already in place). If there is none, then I think it can be quickly formatted into right one using for example https://atom.io/packages/standard-formatter
   An ideal JS project should have one code style from the beginning to the end. So this argument lacks importance with me.
2. I think it does check all the things you are checking. Even unused variables.
3. standard.js does support linting any environment. For example jsx support is built in.
4. if that would fix it, that would be marvellous. Unfortunately for me, when I try to run that in my atom, it does not fix those spaces in function declarations/arrow function argument parens

[robertrossmann]

Sorry for taking my time with this, totally forgot about it!

The argument about gradual adoption of ESLint into existing projects is not just about having consistent coding style from start to end (there's no need for discussion about that - I totally agree!) - the point was, that with this ruleset, you can start using ESLint in projects where there previously was no static code checker and have it only run the known-errors checks, completely ignoring coding style rules and still gain benefits of static code checking. You cannot have that with standard.js - you either install standard.js and are fully compliant or you end up with a project with so much ESLint warnings that you effectively start ignoring them completely.

Additionally, this being an "STRV-made" ruleset, I personally feel it will give people more incentive to use it for our projects and to adhere to the coding styles this ruleset sets forth. 😄 And, since standard.js is maintained by an outside party, we have little flexibility in adopting our own rules should we have the need for that.

The ultimate goal I hope to achieve one day is to have all our projects with this ruleset enabled to its full potential and have near-zero overrides in project-local configuration files.

For these reasons I will now close this. Note, however, that changing some coding style rules can always be discussed via separate issues - there have been several such occurrences already, see #2, #8 as examples. if you have something specific in mind, feel free to raise an issue!