Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chore: avoid hard-coding the list of core rules in eslint:recommended #11336

Merged
merged 2 commits into from Jan 30, 2019

Conversation

not-an-aardvark
Copy link
Member

What is the purpose of this pull request? (put an "X" next to item)

[x] Other, please explain:

What changes did you make? (Give an overview)

This updates the eslint:recommended config to be generated dynamically rather than being hard-coded, to reduce the number of places that need to be kept up to date when core rules are added.

Is there anything you'd like reviewers to focus on?

I was considering doing the same thing for tools/rule-types.json, but after looking at it again I'm not actually sure why tools/rule-types.json exists at all. Is there a reason to keep that file around? It was useful for reviewing the original PR that added rule types, but it doesn't seem like the rule types file is being used for anything.

This updates the `eslint:recommended` config to be generated dynamically rather than being hard-coded, to reduce the number of places that need to be kept up to date when core rules are added.
@not-an-aardvark not-an-aardvark added the chore This change is not user-facing label Jan 30, 2019
Copy link
Member

@g-plane g-plane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this work. Just left a note.

"yield-star-spacing": "off",
yoda: "off"
}
rules: Object.assign({}, ...Object.keys(builtInRules).map(ruleId => ({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using Array.prototype.reduce can remove Object.assign and Array.prototype.map. And there is only one {} while using Object.assign needs many objects.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel strongly about it either way, but I think using Object.assign here is better because it's not necessary to mutate an accumulator object, and it's still O(n). Creating the extra objects is a one-time cost that only happens when the module is loaded.

Copy link
Member

@ilyavolodin ilyavolodin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't have time to check right now, but some of this stuff is used to generate rules page on the website and also for the demo. Could you verify that neither of those things would be affected by this change? Otherwise - looks good.

@not-an-aardvark
Copy link
Member Author

I've verified that the website generation and the demo both use the entire list of rules and check the meta.docs.recommended property themselves rather than looking at eslint:recommended, so I don't think this should be an issue.

@not-an-aardvark not-an-aardvark merged commit dccee63 into master Jan 30, 2019
@not-an-aardvark not-an-aardvark deleted the autogenerate-recommended branch January 30, 2019 22:45
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Jul 30, 2019
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Jul 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
archived due to age This issue has been archived; please open a new issue for any further discussion chore This change is not user-facing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants