Setup loose linting

[Download]

@minecrawler see #4 and #9

[minecrawler]

Since you mention "loose", what exactly should we put in there? Make our own spec? Decide for a modified one (such as JSSS)? What kind of rules do we want to see?

Here are the important points I want to see:

• Should result in safe and standard-conformant JS
  • For example, deprecated methods and properties, like __proto__, should result in an error
• Should result in readable code (readable for someone unfamiliar with the code base)
  • The source we write will be transpiled, so the LoC should not be a metric.
  • Shorthands (ternary, default-or, etc) should be used with care, and only in situations which are clear and understandable to someone who is not familiar with the codebase (the transpiler can do the rest)
  • The code should be divided into logical blocks of code for a better visual separation
  • Comments should be used to explain what a certain function or block does (I suggest JSDoc-Style)
• Should result in performant code
  • Operations, which might be transpiled to sub-optimal code, might be written complexly, but should have an explanation comment attached as to why that style was used
• Linting should not depend on a certain IDE or editor, but be available cross-platform and cross-environment (for example eslint)
• Should enforce invisible style rules, like CRLF vs LF, tabs vs spaces, etc.

[Download]

For example, deprecated methods and properties, like proto, should result in an error

The code is using __ proto __ atm. How could we rewrite this so it works cross-browser?

The source we write will be transpiled, so the LoC should not be a metric.

Ok. But can we agree that the transpiled code size should be a metric?

Comments should be used to explain what a certain function or block does (I suggest JSDoc-Style)

I tried this once but had much difficulty with it. So I decided to move the comments into the readme (since many people won't read the actual code). If you know how to use this I would love to learn. Because it could also help us to generate readable documentation. So yes, all for it!

I basically agree with you on everything. 👍

EDIT: Oops the questions:
I'm hoping we can create a custom linting config that is as close to 'a standard' setup as possible without it becoming religious. For me the no-hoisting and always-triple-equals rules are religious.
Main point of this PR is to establish a baseline that doesn't end up rewriting the whole codebase. Any 'controversial rules' we can debate in separate PR(s), so at least the linting itself can go ahead without too much discussion. 👍

[minecrawler]

The code is using __ proto __ atm. How could we rewrite this so it works cross-browser?

See #16

Ok. But can we agree that the transpiled code size should be a metric?

Yes, definitely!

I tried this once but had much difficulty with it

I once had problems, too, but it is supported by many tools and really simple once you grasp the basics. I can make a PR with trivial JSDoc comments. We do not need them for every little thing, but having them for the most-used functions would be nice :)

custom linting [..] Any 'controversial rules' we can debate in separate PR(s)

OK. I will write a separate file with a few rules, which conforms 90% to what you already have, but makes the code more readable imho. After that, we can think about gradual steps for changing the source linting :)

[Download]

Great plan! 👍