I'd like to have a rule that enforces some strict conventions on identifier names. camelcase also allows PascalCase and with id-match it's impossible to enforce this:

// Valid
const foo = getString();
// Invalid
const Foo = getString();
// Invalid, also conflicts with new-cap
const foo = createClass(); // function createClass(): new (...args: any[]) => any
// Invalid
const foo: React.FC = ...;
// Any name is [in]valid?
const foo = Math.random() < 0.5 ? createClass() : createString();

It also was a limitation for tslint, so there are few relevant issues:

• Can't use Pascal case when declaring a stateless functional component (SFC) palantir/tslint-react#120
• naming-convention: constructorVariable ajafff/tslint-consistent-codestyle#49
• naming-conventions: question - recognize if variable is primitive ajafff/tslint-consistent-codestyle#125

I'm not really sure what kind of configuration fits this rule (or multiple rules?). For me it would be enough to have a stricter version of camelcase that keeps all classes and functions returning JSX.Element in PascalCase and everything else in camelCase, but for some more complex cases it may be worth to have extensible configuration, similar to naming-convention from tslint-consistent-codestyle, which also would cover #515.