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

Enhancement: @typescript-eslint/naming-convention enum values in PascalCase #6592

Closed
4 tasks done
Conaclos opened this issue Mar 9, 2023 · 1 comment
Closed
4 tasks done
Labels
default rule options Discussions about default rule options enhancement: plugin rule option New rule option for an existing eslint-plugin rule package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin wontfix This will not be worked on

Comments

@Conaclos
Copy link

Conaclos commented Mar 9, 2023

Before You File a Proposal Please Confirm You Have Done The Following...

My proposal is suitable for this project

  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/naming-convention/

Description

As notes in a stackoverflow thread, by default ESLint naming-convention rule enforces camelCase for enum values.

This is really strange because I am not aware of any style guide that encourages this convention. Generally style guide encourages the use of PascalCase or CONSTANT_CASE.

I propose to change the default behavior to PascalCase for enum values.

Note that enum value are also types, this should thus be consistent with the existing defaults.

Fail

enum Direction {
  prev,
  next,
}

Pass

enum Direction {
  Prev,
  Next,
}

Additional Info

No response

@Conaclos Conaclos added enhancement: plugin rule option New rule option for an existing eslint-plugin rule package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for maintainers to take a look labels Mar 9, 2023
@bradzacher
Copy link
Member

bradzacher commented Mar 9, 2023

The default isn't there as a "this is the way to do things for everyone". Instead it's there as a quick proxy for the old camelcase lint rule. It's there as an example to show what you could do with the rule.
Its rare that the default will truly match a codebase's naming convention - in which case they will have to design their own config.

This exact default has been in place for 2 years and this is the first time someone has asked for a change. Either that means that (a) few people use the rule so nobody has noticed, (b) the people that use the rule don't use the default or (c) people are happy with the default.

In either case, I don't see a compelling argument for us to change the default here, given that it is a breaking change for us to change defaults and would be very disruptive to users that rely on them.

@bradzacher bradzacher closed this as not planned Won't fix, can't repro, duplicate, stale Mar 9, 2023
@bradzacher bradzacher added wontfix This will not be worked on default rule options Discussions about default rule options and removed triage Waiting for maintainers to take a look labels Mar 9, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
default rule options Discussions about default rule options enhancement: plugin rule option New rule option for an existing eslint-plugin rule package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants