Centralize and simplify ESLint config

[geoffrich]

Is your feature request related to a problem? Please describe.

Our ESLint config has way too many rules (200+ lines of rules in addition to the recommended config), including multiple deprecated rules and rules that are already off by default explicitly turned off. In addition, it's easy for the config to get out of sync between projects and when changes are made in one component's config they aren't made in the other component packages.

Describe the solution you'd like

We should put our ESLint config into it's own repo + package (eslint-config-auro?), so that changes can be made in one place and components simply have to extend the config and update to the latest package to get the changes.

This will also allow devs to open PRs/issues on the repo if they want to propose code style changes.

Describe alternatives you've considered

Extend someone else's config and don't maintain this ourselves. We'll probably want to make tweaks to it though, in which case we're back to the problem of making the same ESLint changes across 20 (and counting) components.

Additional context

Motivated by #61, a change we'll want to make across every component. Putting our ESLint config into a package should make this easier.

[blackfalcon]

I have considered exactly this. The question discussed at that time was to create a supporting lib much like WCSS. That way users can pull in this lib and pick-and-choose what additional 'directives' they want to use.

This issue brings up a concern for a code dependency during development.

For this specific issue, I have looked at using https://eslint.org/docs/developer-guide/shareable-configs in the past.

Extend someone else's config and don't maintain this ourselves.

This one I looked into as well, but the use of esLint across the floor was amazing low and no one had good recommendations to start from. Doing a quick search, there are a few recommendation projects out there, but they are really out of date.

[blackfalcon]

@geoffrich

Defining our own esLint is a very large task. Others like Google or AirBnB have done amazing work to define these rules. Is there a current style guide that we want to adopt?

I feel that it will be impossible to create our own style guide until we draw a line in the sand and define a starting point. Currently, that starting point is the basic install of esLint.

My vote is for using eslint-config-airbnb-base and starting there?

And using this, does that then negate the need to store our config in the cloud?

[geoffrich]

Using someone else's config as a base makes sense, since creating a style guide is a lot of work.

I think it would still be good to store our config in a package/repo. That way there's one place to make updates. We'll likely want to override some settings and add stuff like lit-element linting.

Unless we could have the config live in the generator and have it updated with the work done for #68?

[blackfalcon]

So the scenario is this.

1. Support something like AirBnb config where the config is in a versioned npm
2. If there are customizations that differ from the AirBnb config, then we need a cloud solution to ensure that all repos are up to standard without manual updates

I think for No.2 we need to go with the sharable config idea above so that updates can be pushed to each repo without having to manually update anything.

[blackfalcon]

See https://github.com/AlaskaAirlines/auro-eslint-config to support this update.