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

feat(eslint-plugin): [no-type-alias] support tuples #775

Merged
merged 8 commits into from Aug 19, 2019

Conversation

ankeetmaini
Copy link
Contributor

Fixes #720

@typescript-eslint
Copy link
Contributor

Thanks for the PR, @ankeetmaini!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!


🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint

Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good idea but not quite right.
the reason that the cases failed is because we never added handling for TSTupleType.

What we will want to do instead is:

  • add back the undhandled case error.
  • add a new option allowTupleTypes, which follows the same schema as allowMappedTypes.
  • add in a new clause in validateTypeAliases which handles TSTupleType

@bradzacher bradzacher added the bug Something isn't working label Jul 29, 2019
@ankeetmaini
Copy link
Contributor Author

Thanks @bradzacher, updated the PR :)

@bradzacher bradzacher added enhancement: plugin rule option New rule option for an existing eslint-plugin rule and removed bug Something isn't working labels Jul 30, 2019
@bradzacher bradzacher changed the title fix(eslint-plugin): [no-type-alias] unhandled type feat(eslint-plugin): [no-type-alias] support tuples Jul 30, 2019
Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

awesome! code lgtm. nice work covering everything well.
thanks for doing this.

@bradzacher bradzacher added the 1 approval PR that a maintainer has LGTM'd - any maintainer can merge this when ready label Jul 30, 2019
@ckknight
Copy link

ckknight commented Aug 2, 2019

Can we also have a test for readonly tuples?

Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's actually an interesting point - this rule doesn't support TSTypeOperator at all.

Considering the existence of readonly [tuple], this should also add support for that.

Wouldn't be a huge change to also support the keyof operator too.

@ankeetmaini
Copy link
Contributor Author

ankeetmaini commented Aug 7, 2019

if (type.node.type === AST_NODE_TYPES.TSTypeOperator) {
  if (
    (['keyof', 'readonly'].includes(type.node.operator) &&
    type.node.typeAnnotation &&
    type.node.typeAnnotation.type === 'TSTupleType'
  ) {
    return true;
  }
}

type.node.typeAnnotation.type === 'TSTupleType'

TS is throwing on this line This condition will always return 'false' since the types 'AST_NODE_TYPES.TSTypeAnnotation' and '"TSTupleType"' have no overlap.ts(2367)

How else can I ascertain that TSTypeOperator contains a tuple type? I checked the AST too, it seems valid https://astexplorer.net/#/gist/149c54ba8d9a45dace62a4aac639f613/79446ea665c469c0e03fe7a74fdeb35ac7bbcde5

@bradzacher
Copy link
Member

try AST_NODE_TYPES.TSTupleType

@bradzacher bradzacher removed the 1 approval PR that a maintainer has LGTM'd - any maintainer can merge this when ready label Aug 7, 2019
@ankeetmaini
Copy link
Contributor Author

It fails with that too. :(

@bradzacher
Copy link
Member

bradzacher commented Aug 8, 2019

@bradzacher
Copy link
Member

The types were wrong for TSTypeOperator. I fixed them for you on this branch.

@ankeetmaini
Copy link
Contributor Author

@bradzacher thanks, I've updated the tests and rebased with master.

Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for doing this

@bradzacher bradzacher added the 1 approval PR that a maintainer has LGTM'd - any maintainer can merge this when ready label Aug 14, 2019
@JamesHenry JamesHenry removed the 1 approval PR that a maintainer has LGTM'd - any maintainer can merge this when ready label Aug 19, 2019
@JamesHenry JamesHenry merged commit c68e033 into typescript-eslint:master Aug 19, 2019
@ankeetmaini ankeetmaini deleted the no-type-alias-fix branch August 20, 2019 06:39
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[no-type-alias] unhandled type - shouldn't happen
4 participants