generator: add support for remote esLint config

[blackfalcon]

Alaska Airlines Pull Request

Fixes: #62

Summary:

The scope of this PR removes locally installed eslint configs and update to support the new remote eslint-config

Type of change:

Please delete options that are not relevant.

• New capability
• Revision of an existing capability
• Infrastructure change (automation, etc.)
• Other (please elaborate)

Checklist:

• My update follows the CONTRIBUTING guidelines of this project
• I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.

Thank you for your submission!

-- Auro Design System Team

[geoffrich]

Two questions:

• Is there a reason our config is now in .eslintrc instead of .eslintrc.js? I'm not aware of the implications, but it seems like the docs recommend .eslintrc.js.
• Did we verify that this config works (i.e. scaffold a new component and you can trigger lint errors)?

Otherwise, this PR was a lot less intimidating than I was expecting 😅

[blackfalcon]

• Is there a reason our config is now in .eslintrc instead of .eslintrc.js? I'm not aware of the implications, but it seems like the docs recommend .eslintrc.js.

The .eslintrc is only in the repo to reference the npm's .eslintrc.js

• Did we verify that this config works (i.e. scaffold a new component and you can trigger lint errors)?

[geoffrich]

If the stylelint config moves into the config package as well, I think it should be called something more generic, e.g. @aurodesignsystem/config. What do you think? If we change the name, we should make this PR use the new package before merging.

[blackfalcon]

If the stylelint config moves into the config package as well...

We have to test the scenario out to see if it all works that way. The esLint docs specifically asked for a naming convention, but I am not sure how dependent it is on that convention.

But if it works, then I have no issue with the rename.

[blackfalcon]

So, one step at a time here. Let's get this PR and the Sass lint update PR all merged and then move into the next step. Trying to juggle these PRs that work AND other decisions on the fly that may not work... too confusing.