chore(package): Add ESLint

[ExE-Boss]

This adds a basic ESLint configuration to the project which doesn’t require changing almost every file like #1483 (the goal is to slowly enable rules across multiple PRs).

[RunDevelopment]

Nice work!

Apart from the comments, I also have a more general question:

Quite a number of times multiple variables are declared like this:

var foo,
    bar;

These were aligned using 4 spaces, so that bar is aligned under foo. The new indentation rules forbid this style.
So should try to change the ESLint config or should we just use a few vars more?

[LeaVerou]

As I have expressed in the other issue, I disagree with any linting being classed as "error". It should be warnings, and errors should be reserved for actual JS errors. A wrong indent is not the same importance as a JS parse error that breaks the whole script.

[mAAdhaTTah]

@LeaVerou Is that to suggest we can merge in PRs with warnings? We could switch warnings -> errors in CI if not, so they're just warnings during development.

[LeaVerou]

Oh I wasn't even thinking about CI. I primarily find ESLint useful as an authoring environment plugin that highlights errors and warnings inline. I would find it frustrating if it highlighted syntax errors and stylistic issues the same way.

[mAAdhaTTah]

Sounds good, so we should bump warnings -> errors in CI and downgrade style issues to warnings during development.

[ExE-Boss]

And how do you propose to do that?

[mAAdhaTTah]

This might work. Another suggestion is to use a .js file for config and use env vars. There's a package called is-ci that could help here.

[RunDevelopment]

We could also check the output of eslint and throw if we got any warnings.

[LeaVerou]

I saw some back and forth on dangling commas. My opinion is that if there is not near 100% consensus on a linting rule, I'd suggest not enforcing one either way. We don't need to control every single aspect of code style via linting, especially if they haven't been enforced so far at all. We don't need to provide a value for every single rule ESLint supports. Linting should help our work, not get in the way, and overly strict linting can easily get in the way.
Just my 2 cents, take it or leave it!

[RunDevelopment]

@ExE-Boss Sorry, I did expect to be able to push to your branch. I reverted everything and made a PR.

[RunDevelopment]

The only things left to discuss now are:

1. How to handle joint variable declarations.
   Do we want to leave the tabs as is or should we add a few more vars.
   Using spaces is not possible because of "no-mixed-spaces-and-tabs": "error". Smart tabs are possible but a real pain because some formatters (e.g. the one I'm using) don't support them.
2. The TSC hack.

[mAAdhaTTah]

Ooof, letting this lag will make it very difficult to merge. Are we all aligned on the rules presented here? I might go so far as to suggest slotting this into a potential 2.0 and introduce it in one sweeping change early on there. Thoughts?

[LeaVerou]

Using spaces is not possible because of "no-mixed-spaces-and-tabs": "error". Smart tabs are possible but a real pain because some formatters (e.g. the one I'm using) don't support them.

We should never use tabs for alignment. The codebase uses smart tabs. If we don't want to enforce them with ESLint we should avoid any rules related to indentation for now, not inserting rules that will force us to worsen how we do indentation and alignment! Again, we don't need to lint everything. We can start with a small set of rules and expand as we go.

(Also, if a tool doesn't support smart tabs, I'd consider that a bug and open an issue with them)

[RunDevelopment]

About alignment: Why don't we use Prettier and end the formatting debate?

[LeaVerou]

Does Prettier support smart tabs?

[RunDevelopment]

Just checked. It doesn't and I'd even argue that it doesn't matter. I have yet to come across a formatter that handles smart tabs correctly.
Examples: ESLint doesn't (see above). Clang format (C/C++ formatter that can also do JS) can kinda do it but it assumes that tabs are 8 spaces wide, so the alignment is all messed up with my usual 4 spaces = 1 tab. VSCode's builtin formatter can't do it.

Point is: Which formatter has good support for smart tabs? If there aren't any good formatters that support it, then I don't think this should be a criterion. Manual formatting just isn't feasible and no formatter is a lot worse than a formatter that uses, god forbid, tabs for alignment, IMO.

Don't get me wrong: I think you're correct. Tabs for indentation and spaces for alignment is the indented use for tabs and spaces but if all our automated tools work against us on this matter, it might be easiest to just not care about it.

[RunDevelopment]

Closed in favor of #2831.