`useLiteralKeys`

[ematipico]

3. no-literal-computed-keys (autofix e.g. ["a"] to a, safe)

cc @jeysal

[notmd]

@ematipico I would like to take this one.

[notmd]

I don't really understand the rule. The issue title seems like https://eslint.org/docs/latest/rules/no-useless-computed-key. But the fix suggestion is like https://eslint.org/docs/latest/rules/dot-notation. We didn't have both of these rules yet.

[ematipico]

Sorry for the lack of context. In this issue #3731 there's more information about why we decided to split the ESLint rule into three rules.

They are more specialised, allowing us to give more control and put them in different groups.

[MichaReiser]

Naming. How about noComputedLiteralKeys (or MemberNames) or useLiteralKeys?

[ematipico]

Naming. How about noComputedLiteralKeys (or MemberNames) or useLiteralKeys?

I like these names.

I wonder if we should narrow down the name to include "string", I don't think the rule will be applied to numerical literals, for example.

[jeysal]

I wonder if we should narrow down the name to include "string", I don't think the rule will be applied to numerical literals, for example.

I think it should actually! Any numeric literal should be valid directly as a literal property name (even weird stuff like { .1: 42 } works), so we should also unwrap those out of a computed property name.

Boolean and null literals too (trivial)

[github-actions]

👋 @rome/staff please triage this issue by adding one of the following labels: S-Bug: confirmed, S-Planned , S-Wishlist or umbrella

[jpike88]

this is a super important one, I'd even suggest putting it in the recommended set. It's super dangerous to allow people to accidentally reference a non-literal key due to it sidestepping type checks.