-
Notifications
You must be signed in to change notification settings - Fork 117
Description
Currently we are using a deprecated @typescript-eslint/camelcase rule in our shared linter config, which causes quite a few problems, for example, when we import from @joystream/types (where ie. almost all Struct properties are snake_case to match the names in the runtime).
We may also want to be able to choose some unusual naming conventions like ie.: OpeningType_Leader for enum variant classes.
Experimenting with different options we can provide to @typescript-eslint/naming-convention rule (which is currently recommended instead of @typescript-eslint/camelcase), I was able to come up with a configuration that works well enough for our current @joystream/types workspace (only forcing ~10 renames):
'@typescript-eslint/camelcase': 'off',
'@typescript-eslint/class-name-casing': 'off',
"@typescript-eslint/naming-convention": [
"error",
{
selector: 'default',
format: ['camelCase'],
},
{
selector: 'variable',
format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
},
{
selector: 'property',
format: [] // Don't force format of object properties, so they can be ie.: { "Some thing": 123 }, { some_thing: 123 } etc.
},
{
selector: 'accessor',
format: ['camelCase', 'snake_case']
},
{
selector: 'enumMember',
format: ['PascalCase']
},
{
selector: 'typeLike',
format: [],
custom: { regex: '^([A-Z][a-z0-9]*_?)+', match: true }, // combined PascalCase and snake_case to allow ie. OpeningType_Worker
}
],
It doesn't mean that we should use all those rules in shared config (ie. allowing PascalCase for variables), but we could use it to create an extandable set that would be the most common naming convention in our TypeScript projects.
For reference see: https://github.com/typescript-eslint/typescript-eslint/blob/v2.32.0/packages/eslint-plugin/docs/rules/naming-convention.md