Skip to content

Rule rename: no-array-constructor -> array-constructor #6034

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.

Sign up for GitHub

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

Jump to bottom
Closed
JoshuaKGoldberg opened this issue Nov 19, 2022 · 3 comments
Closed

Rule rename: no-array-constructor -> array-constructor #6034

JoshuaKGoldberg opened this issue Nov 19, 2022 · 3 comments
Labels
enhancement New feature or request package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin wontfix This will not be worked on

Comments

@JoshuaKGoldberg
Copy link
Member

JoshuaKGoldberg commented Nov 19, 2022 •
edited
Loading

Overview

Porting context from #6022 > #6022 (comment):

A number of the no- rules make sense as things that won't be turned on and have no inverse, so a blanket rule against no- prefixes is a bad idea.
I agree though that it makes sense for us to advise against that naming if it's feasible that we will add inverse functionality to a rule.

@typescript-eslint/no-array-constructor is mentioned as a potential rule to rename:

  • has no inverse
  • maybe should be renamed though because it sounds like you shouldn't use any array constructors, when it's only enforcing correct usage.

Personally, I'm on the fence of whether a different name would be better, and don't mind either way. Which makes me lean slightly towards keeping it the same, just to reduce changes.

@bradzacher, did you have a different name in mind?
@JoshuaKGoldberg JoshuaKGoldberg added enhancement New feature or request package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Nov 19, 2022
@Josh-Cena
Copy link
Member

If it's a base rule extension, shouldn't it be more in our interest to align with the base rule's name? (I'm aware we don't do that for no-return-await, but that's because we actually have an inverse for returning await)

@bradzacher
Copy link
Member

Yeah it's probably a rename that would need to be upstreamed
In terms of naming - probably should be something like prefer-array-literal

@JoshuaKGoldberg
Copy link
Member Author

Copying from @nickmccurdy's #6022 (comment):

Can we at least keep the no- prefix for extension rules? I don't think the benefits of simplifying the APIs apply to rules that are already in ESLint, and this makes migrating from ESLint rules more confusing.

I agree that it's confusing for users. Since unlike (no-)return-await we don't have options to invert it, I'm going to close this out. Thanks all!

@JoshuaKGoldberg JoshuaKGoldberg added wontfix This will not be worked on and removed triage Waiting for team members to take a look labels Nov 23, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement New feature or request package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin wontfix This will not be worked on
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@JoshuaKGoldberg @bradzacher @Josh-Cena