Description
For some reason, when you refactored to typescript everywhere, the choice was made to write an entire set of unconventional AST types rather than extending ESTree/ESLint types.
Out of interest, why was this?
This leads to all sorts of weirdness when mixing ESLint types in. You get away with it here because you literally rewrote all of ESLint's types and use those instead (from a pseudo-module?).
I do see the comments at the top of that file, too. But avoiding compromising type compatibility with ESLint entirely seems like it should have outweighed your need for "better control".
- It means we can't
context.reporta "TSESTree" node if we're strictly implementing ESLint's types as we should (rather than your cloned types) - It means a typescript-eslint
RuleModuleisn't an ESLintRuleModule - Your node types use an enum but really should use constant string types for consistency with ESTree (example vs yours. this is pretty unconventional/inconsistent, especially since some of your types even use string constants rather than the enum)
- We can't really make plugins which use typescript-eslint nodes because your types are internal? (your cloned types, i.e. RuleModule and friends)
Surely you would have been better off extending the ESTree types and being compatible with ESLint, being that you're implementing an ESLint plugin after all.
is there some reason you went down this path?
We are struggling to move our plugins over to typescript-eslint from the obsolete tslint project because of this.