Typescript enum migration to eraseable syntax - naming convention poll

[nazarhussain]

Problem

In Typescript we the struct enum is unique that it combine value and type information together. We want to use TS5.8 eraseableSyntaxOnly feature to adapt to future TS support in NodeJS.

In that syntax we can't mix up the types and values together so we have to split all enum to pair of values+types manually. Take this example.

enum ImportStatus {
  Imported = "Imported",
  Duplicate = "Duplicate",
  Error = "Error",
}

Solution

This needs to be divide into two declarations , one for value and one for type. We can't use same name for both declarations so question came up what names do we use for both and how to enforce the linting rules to have consistent code.

And we want to have such naming convention that can be enforced by the linter. Our general rule is to allow camelCase for all variable/cost declarations but we want exception for enum values to have PascalCase.

Our linter currently can only support regular expression matching on the names of the declarations so any suffix/prefix will help us to identify if it's a enum value declaration or just a normal variable. So please vote for any of pattern below which you feel more aligned with or comment with your suggestion otherwise.

Pattern 1 - capital case enum + camelCase values

const importStatus = {
  Imported: "Imported",
  DuplicateL "Duplicate",
  Error = "Error",
} as const;

type ImportStatus = EnumLike<typeof importStatus>;

1. Keep the linting rules consistent without exception
2. All variables with camelCase and all type declarations are PascalCase
3. We may have conflict with local variables names, or function parameters names

Pattern 2 - Capital case values with Enum suffix type

const ImportStatusEnum = {
  Imported: "Imported",
  Duplicate: "Duplicate",
  Error: "Error",
} as const;

type ImportStatus = EnumLike<typeof ImportStatus>;

1. Introduce naming convention exception for such variables

Pattern 3 - Capital case values with Values suffix type

const ImportStatusValues = {
  Imported: "Imported",
  Duplicate: "Duplicate",
  Error: "Error",
} as const;

type ImportStatus = EnumLike<typeof ImportStatusValues>;

1. Introduce naming convention exception for such variables

Pattern 4 - Allow all variables to be both PascalCase or camelCase.

const ImportStatus = {
  Imported: "Imported",
  Duplicate: "Duplicate",
  Error: "Error",
} as const;

type ImportStatusType = EnumLike<typeof ImportStatus>;

1. No linting rule exception

Pattern 5 - Plural for value and singular for type

const ImportStatuses = {
  Imported: "Imported",
  DuplicateL "Duplicate",
  Error = "Error",
} as const;

type ImportStatus = EnumLike<typeof ImportStatuses>;

1. The linting will enforce value as any variable ending with s must be PascalCase
2. That can result into false positive as well

[nazarhussain]

@nflaig Please be aware that with Pattern 5 there could be a lot of false positives. There can be many variable names which are not related to enum, but linter will enforce those to PascalCase.

[nflaig]

I don't understand why we feel so strongly about having this linter enforced, we don't really enforce naming of variables right now either, we only ensure casing is somewhat correct

eg. this is allowed right now

const a = 123123;

Awful variable name, but linter is fine with it, this is something we can catch in the review process

[wemeetagain]

I'm voting for 4 + 5

No linter rule (allow camel and pascal)
Convention to use plural for the variable, singular for the type

[nazarhussain]

Option 4 seems more intuitive anyone reading the code or a new person contributing. They will understand Type suffix more naturally than the plural vs singular concept (unless explained).

[matthewkeil]

I tend to agree with @wemeetagain, Pascal and camel are both valid cases for variable names. No linter rule, or set rule for to allowing both. And for enums use plural for the values and singular for the type. I say that though with a caveat, English being the wonderfully caveated language that it is (in particular with regards to plurals) there will be inconsistencies for doing this. I tend to lean towards a suffix on either the value or the type but it seems like team consensus is strongly against that already. With the suffix veto in mind i think singular/plural is the best of the remaining options.

[matthewkeil]

I accidentally voted for 5 but really prefer 4.... 🤦‍♂️

[nflaig]

admit it you hate suffixes as much as I do

[ensi321]

Voted 4, but prefer some suffix other than Type for type

[nflaig]

but prefer some suffix other than Type for type

es?

[nazarhussain]

I wish all plurals have es suffixes, but it's not. That I learned very late in high school.

[nflaig]

I wish all plurals have es suffixes, but it's not. That I learned very late in high school.

yes, I am just messing around, ignore my spam 😅

[nazarhussain]

After a lot of brainstorming and discussion we decided to move with Enum suffix pattern.

const ImportStatusEnum = {
  Imported: "Imported",
  Duplicate: "Duplicate",
  Error: "Error",
} as const;

type ImportStatus = EnumLike<typeof ImportStatusEnum>;

A reference PR related to this discussion ChainSafe/benchmark#31