Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
Description
Before You File a Proposal Please Confirm You Have Done The Following...
- I havesearched for related issues and found none that match my proposal.
- I have searched thecurrent rule list and found no rules that match my proposal.
- I haveread the FAQ and my problem is not listed.
My proposal is suitable for this project
- I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).
Link to the rule's documentation
https://typescript-eslint.io/rules/no-type-alias
Description
Template Literals is a powerfull TypeScript feature, allowing to specify exact form a string may take. Using template literals allows to force specific input form, eg:
typeJiraTicketNumber= `${'PROJ01'|'PROJ02'}-${number}`typeChatCommand= `/${keyoftypeofcommands}`typeFilterField= `${'include'|'exclude'}: ${string}`typeLang='en'|'de'|'es'typePage='home'|'blog'|'store'typeURLSlug= `/${Lang}/${Page}`
but also allowing to mapping keys to another type (see examples in link above).
There might be (and in my case actually is) a case, where type aliasing is generally not allowed (apart from unions / intersections), with template literal being exception, as it's recommended to share the single definition of this type rather than have to use the template literal type in many different places, as that may lead to issues when the form of the template literal type changes.
I'd love to suggest adding newallowTemplateLiterals
option that would handle such case. Template Literals are a new, unique form of typescript type and while there is an option to whitelist any other type (mapped types, generics, tuples, literals, etc), there is no real way to whitelist template literals.
Fail
// with allowTemplateLiterals: false (default)typeSlashCommand= `/${string}`
Pass
// with allowTemplateLiterals: true (default)typeSlashCommand= `/${string}`
Additional Info
For reference,#5092 (unmerged at the time of creating this issue) adds handling of type literals which are unhandled in current version of the plugin, see#5043