Enhancement: add strict parent types for nodes that have well-defined parents

[bradzacher]

Right now a node's .parent property is loosely typed as TESTree.Node. This is pretty sucky as it means that users need to either add unnecessary logic or explicit casts to refine types in some cases.

There are a number of nodes wherein we know exactly what the parent node will always be due to the defined structure of the AST.
For example, we know that a VariableDeclarator will always have a VariableDeclaration parent.

We should define some of these simpler relationships in our types to improve the experience of consuming the AST types.

Some cases we can define:

• AccessorProperty has parent ClassBody
• CatchClause has parent TryStatement
• ClassBody has parent ClassDeclaration | ClassExpression | TSAbstractClassDeclaration
• ExportSpecifier has parent ExportNamedDeclaration
• ImportAttribute has parent ImportDeclaration | ImportExpression
• ImportDefaultSpecifier has parent ImportDeclaration
• ImportNamespaceSpecifier has parent ImportDeclaration
• ImportSpecifier has parent ExportAllDeclaration | ExportNamedDeclaration | ImportDeclaration
• JSXAttribute has parent JSXOpeningElement
• JSXClosingElement has parent JSXElement
• JSXClosingFragment has parent JSXFragment
• JSXOpeningElement has parent JSXElement
• JSXOpeningFragment has parent JSXFragment
• JSXSpreadAttribute has parent JSXOpeningElement
• MethodDefinition has parent ClassBody
• Property has parent ObjectExpression | ObjectPattern
• PropertyDefinition has parent ClassBody
• SpreadElement has parent ArrayExpression | CallExpression | ObjectExpression
• StaticBlock has parent ClassBody
• SwitchCase has parent SwitchStatement
• TemplateElement has parent `TemplateLiteral | TSTemplateLiteralType``
• TSAbstractAccessorProperty has parent ClassBody
• TSAbstractMethodDefinition has parent ClassBody
• TSAbstractPropertyDefinition has parent ClassBody
• TSCallSignatureDeclaration has parent TSInterfaceBody | TSTypeLiteral
• TSConstructSignatureDeclaration has parent TSInterfaceBody | TSTypeLiteral
• TSClassImplements has parent ClassDeclaration | ClassExpression
• TSEnumMember has parent TSEnumDeclaration
• TSIndexSignature has parent ClassBody | TSInterfaceBody | TSTypeLiteral
• TSInterfaceBody has parent TSInterfaceDeclaration
• TSInterfaceHeritage has parent TSInterfaceBody
• TSMethodSignature has parent TSInterfaceBody | TSTypeLiteral
• TSModuleBlock has parent TSModuleDeclaration
• TSParameterProperty has parent FunctionLike
• TSPropertySignature has parent TSInterfaceBody | TSTypeLiteral
• TSTypeParameter has parent TSInferType | TSTypeParameterDeclaration | TSMappedType
• VariableDeclarator has parent VariableDeclaration

Note: the implementor should double check that I've written these correctly by comparing them against the AST types.

The import thing to note is that we shouldn't define all of the relationships that exist - just a subset of them that we can easily statically define and maintain. I'd probably put a rule around ~3 parent types being the maximum.

[Josh-Cena]

BaseNode#parent is intentionally added as augmentation in @typescript-eslint/types. If we are to add more parent properties, should this be in the spec?

[JoshuaKGoldberg]

should this be in the spec?

Sorry @Josh-Cena I'd missed this comment till now - what do you mean by "in the spec"? Like, which spec?

[Josh-Cena]

Uh, it was very long ago. I think I meant: should this be in @typescript-eslint/types (like BaseNode#parent), or @typescript-eslint/ast-spec? We augmented the spec in the types package for the BaseNode#parent solely for the purpose of convenience, which means when people look at the AST spec by itself, they won't know about the parent type at all.

[bradzacher]

Yeah there's a difficult thing.
Part of me thinks in the next major we should just start emitting a parent from typescript-estree so that we can hoist the parent property to the spec.