Fix type definitions to fully support Typescript

[dpoindexter]

Q	A
Fixed Issues?	Fixes #6933
Patch: Bug Fix?	Yes
Major: Breaking Change?	No
Minor: New Feature?	No
Tests Added + Pass?	Yes
Documentation PR	No
Any Dependency Changes?	No
License	MIT

This addresses missing or incorrect Typescript types in other type definitions.

For core, experimental, and ES2015 types, any type definition referencing a Flow node type (for example, the typeParameters property of the ArrowFunctionExpression node type) now also allows the equivalent Typescript node type. (In the case of ArrowFunctionExpression.typeParameters, allowed types became TypeParameterDeclaration | TSTypeParameterDeclaration | Noop.

For Typescript types, any type definition referencing a Flow node type replaced that reference with the equivalent Typescript node type. For example, in TSInterfaceDeclaration.typeParameters, allowed types became TSTypeParameterDeclaration rather than TypeParameterDeclaration.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/6100/

[existentialism]

Guess one thing to think about, is that this change will make tSDeclareMethod and tSDeclareFunction (which spread in functionCommon) accept TypeParameterDeclaration.

[dpoindexter]

Good catch -- I missed that. Would you rather override the property for the TS types, or compose more granularly?

defineType("TSDeclareFunction", {
  ...functionCommon,
  returnType {
    ...functionCommon.returnType
    validate: ...etc
  },
  typeParameters: {
    ...functionCommon.typeParameters,
    validate: ...etc.
  }
});

vs.

export const functionCommon = {
  // everything there now but returnType and typeAnnotation
}

// only used for core types that need to accept either Flow or TS nodes
const functionCommonWithTypes = {
  returnType: {},
  typeAnnotation: {}
}

I didn't see other examples of overriding spread properties in definintions -- if that's generally the case, then the second approach might be more consistent with the rest of the code.

[existentialism]

Yeah let's go with the second 👍

[dpoindexter]

@existentialism It's not immediately obvious because I squashed the commit, but this has been addressed.

I split the type annotations out of functionCommon into functionTypeAnnotationCommon, and spread both objects on the relevant core/es2015 types.

functionDeclarationCommon and classMethodOrDeclareMethodCommon still spread just functionCommon. Types that use those now also spread either functionTypeAnnotationCommon or tSFunctionTypeAnnotationCommon as appropriate.

[existentialism]

@dpoindexter thanks again!