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]: add allowGenerics option #3865

Merged

Conversation

scottohara
Copy link
Contributor

@scottohara scottohara commented Sep 9, 2021

Fixes #3784

(⚠️ Note: an earlier version of this PR introduced an allowedAliasNames: [] option which accepted an array of strings to ignore. This was later swapped to an allowGenerics: 'always' | 'never' option that permits/prevents any TSTypeReference that has parameters)

This change adds an option to no-type-alias to allow generics to be ignored by the rule.

The new option is allowGenerics, and can be set to "always" or "never" (default is "never"), e.g.

{
  "@typescript-eslint/no-type-alias": ["error", { "allowGenerics": "always" }]
}

As discussed in #3784, the main driver for this change is to avoid a conflict when using both consistent-indexed-object-style and no-type-alias with their default options.

Specifically to allow the following code to pass both rules:

type Foo = Record<string, number>;

@typescript-eslint
Copy link
Contributor

Thanks for the PR, @scottohara!

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. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

@bradzacher bradzacher added the enhancement: plugin rule option New rule option for an existing eslint-plugin rule label Sep 9, 2021
@codecov
Copy link

codecov bot commented Sep 9, 2021

Codecov Report

Merging #3865 (e862229) into master (4a88de2) will increase coverage by 0.83%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #3865      +/-   ##
==========================================
+ Coverage   92.70%   93.53%   +0.83%     
==========================================
  Files         329      149     -180     
  Lines       11534     8049    -3485     
  Branches     3257     2553     -704     
==========================================
- Hits        10693     7529    -3164     
+ Misses        368      164     -204     
+ Partials      473      356     -117     
Flag Coverage Δ
unittest 93.53% <100.00%> (+0.83%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
packages/eslint-plugin/src/rules/no-type-alias.ts 100.00% <100.00%> (ø)
...tal-utils/src/ast-utils/eslint-utils/predicates.ts
packages/typescript-estree/src/node-utils.ts
packages/scope-manager/src/lib/es2018.intl.ts
packages/scope-manager/src/lib/es2015.symbol.ts
...ages/scope-manager/src/referencer/ExportVisitor.ts
packages/scope-manager/src/lib/es2016.full.ts
packages/scope-manager/src/lib/es2019.string.ts
packages/scope-manager/src/scope/TSModuleScope.ts
packages/scope-manager/src/lib/es2019.symbol.ts
... and 171 more

@JounQin
Copy link
Contributor

JounQin commented Sep 12, 2021

I think an optionallowGeneric could cover these usages automatically?

@scottohara
Copy link
Contributor Author

Hi @JounQin,

Thanks for your suggestion of allowGeneric and for the pointer to #3181 (which I apologise I had not previously seen).

I think I agree with you that an allowGeneric option would be a simpler & cleaner solution than the allowedAliasNames one in this PR.

To confirm, for declarations like:

type Foo = Record<string, number>;
type Bar = Readonly<Foo>;
// etc.

...the allowGeneric option would permit any TSTypeAliasDeclaration where:

  1. typeAnnotation.type === AST_NODE_TYPES.TSTypeReference and
  2. typeAnnotation.typeParameters !== undefined

I'm interested to understand whether the option also needs to support some of the other elements of your no-restricted-syntax selector such as

  • .typeAnnotation[type=/^TS.*Keyword$/]
  • :not(:has(TSQualifiedName))

?

Are there any other forms of generic declarations (other than TSTypeReference) that we need to cater for?

@JounQin
Copy link
Contributor

JounQin commented Sep 13, 2021

@scottohara Personally I'd love to see an option to cover my use case which only disallows simple alias, but for allowGeneric I don't think it's its responsibility.

@scottohara scottohara changed the title feat(eslint-plugin): [no-type-alias]: add allowedAliasNames option feat(eslint-plugin): [no-type-alias]: add allowGenerics option Sep 13, 2021
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.

thanks for this!

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] Allow exception for Record<T, U> to avoid conflict with consistent-indexed-object-style
3 participants