Closed
Description
This is using the example in the docs titled "Enforce the codebase follows ESLint's camelcase conventions".
aka: how do you handle this in your own repo? I can't find any custom alterations to naming-convention, but your CI is passing?
I don't have a direct issue with being stricter than ESLint's version of camelcase, I feel it's important to provide drop-in replacement examples for the behavior of previous rules.
Repro
{
"rules": {
"@typescript-eslint/naming-convention": [
"error",
{
"selector": "default",
"format": ["camelCase"]
},
{
"selector": "variable",
"format": ["camelCase", "UPPER_CASE"]
},
{
"selector": "parameter",
"format": ["camelCase"],
"leadingUnderscore": "allow"
},
{
"selector": "memberLike",
"modifiers": ["private"],
"format": ["camelCase"],
"leadingUnderscore": "require"
},
{
"selector": "typeLike",
"format": ["PascalCase"]
}
]
}
}export = ESLintUtils.RuleCreator(name => name)({
name: __filename,
meta: {
type: 'problem',
docs: {
description: 'Ensures rules are valid.',
category: 'Best Practices',
recommended: 'error'
},
messages: {
ohNoes: 'Oh Noes!'
},
schema: []
},
defaultOptions: [],
create(context) {
return {
Literal(node) {
context.report({
node,
messageId: 'ohNoes'
});
}
};
}
});Expected Result
No linting errors.
Actual Result
ESLint: Method name Literal must match one of the following formats: camelCase(@typescript-eslint/naming-convention)
Additional Info
Versions
Also tried against canary.
| package | version |
|---|---|
@typescript-eslint/eslint-plugin |
2.16.0 |
@typescript-eslint/parser |
2.16.0 |
TypeScript |
3.7.5 |
ESLint |
6.8.0 |
node |
12.14.1 |
npm |
6.13.6 |