feat(eslint-plugin): add "enum-const-style" rule #290
Conversation
0c94702 to
69b371e
Compare
|
Thank you for your contribution! I'd like to separate rules, and in order to separate, would you change the rule name as narrowing? |
|
Thank you for update! Code and tests look good to me. And would you reorder the document content a bit? # title (rule ID)
Description of context why you use this rule.
## Rule Details
Description of what the rule does.
## Options
Description of options. |
4c5d2cb to
24042d8
Compare
|
I don't get any coverage errors locally. How can I re-run it? |
|
depends on editor, in Intelij Idea i'm just pressing for vscode you will need plugin https://github.com/jest-community/vscode-jest#how-do-i-show-code-coverage |
|
if you cd into the plugin folder (rather than just in the project root), then run |
25dd589 to
4b1292a
Compare
|
I don't see the failure report in codecov. Can you point me to what's actually not passing? |
|
We have a minimum target of 90% coverage on the files that a PR changes. It's because your file is so short, so one line really messes up the total %age. |
|
One piece of feedback for you with your PRs - don't use the ammend + force push workflow when submitting PRs. Doing so makes it hard for us to review because git/github doesn't track the old versions of the same commit, which means that we can't compare your new changes to the previous changes. i.e. we have to re-review the entire PR each time you push, because we don't know what has changed. |
…t-eslint into mohsen1--enum-style
c386cdb to
3715b5f
Compare
|
@mohsen1 when do you think you’ll have chance to review the feedback? |
|
Hi @mohsen1, just following up on this again as it's been a few months since the last comment |
| Examples of **incorrect** code for this rule with `always` config: | ||
|
|
||
| ```ts | ||
| enum const Foo { |
There was a problem hiding this comment.
| enum const Foo { | |
| const enum Foo { |
| ### Default config: `never` | ||
|
|
||
| ```JSON | ||
| { | ||
| "enum-const-style": ["error", "never"] | ||
| } | ||
| ``` | ||
|
|
||
| Examples of **incorrect** code for this rule with `never` config: | ||
|
|
||
| ```ts | ||
| enum Foo { | ||
| ONE, | ||
| TWO, | ||
| } | ||
| ``` | ||
|
|
||
| Examples of **correct** code for this rule with `never` config: | ||
|
|
||
| ```ts | ||
| const enum Foo { | ||
| ONE, | ||
| TWO, | ||
| } | ||
| ``` | ||
|
|
||
| ### `always` config | ||
|
|
||
| Only const enums are allowed | ||
|
|
||
| Examples of **incorrect** code for this rule with `always` config: | ||
|
|
||
| ```ts | ||
| enum const Foo { | ||
| ONE, | ||
| TWO, | ||
| } | ||
| ``` | ||
|
|
||
| Examples of **correct** code for this rule with `always` config: | ||
|
|
||
| ```ts | ||
| const Foo { | ||
| ONE, | ||
| TWO, | ||
| } | ||
| ``` |
There was a problem hiding this comment.
I think the examples are the wrong way around
There was a problem hiding this comment.
actually i haven't read docs, but i did small refactoring in rule source code
Closes #280