Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix type definitions to fully support Typescript #6939

Merged

Conversation

@dpoindexter
Copy link
Contributor

dpoindexter commented Nov 30, 2017

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

This comment has been minimized.

Copy link
Collaborator

babel-bot commented Nov 30, 2017

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

@@ -291,7 +294,11 @@ export const functionCommon = {
optional: true,
},
typeParameters: {
validate: assertNodeType("TypeParameterDeclaration", "Noop"),
validate: assertNodeType(

This comment has been minimized.

Copy link
@existentialism

existentialism Dec 1, 2017

Member

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

This comment has been minimized.

Copy link
@dpoindexter

dpoindexter Dec 1, 2017

Author Contributor

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.

This comment has been minimized.

Copy link
@existentialism

existentialism Dec 1, 2017

Member

Yeah let's go with the second 👍

This comment has been minimized.

Copy link
@dpoindexter

dpoindexter Dec 4, 2017

Author Contributor

@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.

@danez danez added the pkg: types label Dec 2, 2017
@andy-ms
andy-ms approved these changes Dec 4, 2017
@dpoindexter dpoindexter force-pushed the dpoindexter:fix/typescript-type-definitions branch 2 times, most recently from 19e40bd to 69db29b Dec 4, 2017
… Typescript type definitions
@dpoindexter dpoindexter force-pushed the dpoindexter:fix/typescript-type-definitions branch from 69db29b to 3bba280 Dec 4, 2017
@existentialism existentialism merged commit 12ac1bc into babel:master Dec 8, 2017
4 checks passed
4 checks passed
babel/repl REPL preview is available
Details
ci/circleci Your tests passed on CircleCI!
Details
codecov/project 81.08% (target 80%)
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@existentialism

This comment has been minimized.

Copy link
Member

existentialism commented Dec 8, 2017

@dpoindexter thanks again!

@lock lock bot added the outdated label Oct 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.