Enhancement: [no-type-alias] allowTemplateLiterals

[burtek]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read 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:

type JiraTicketNumber = `${'PROJ01' | 'PROJ02'}-${number}`
type ChatCommand = `/${keyof typeof commands}`
type FilterField = `${'include' | 'exclude'}: ${string}`

type Lang = 'en' | 'de' | 'es'
type Page = 'home' | 'blog' | 'store'
type URLSlug = `/${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 new allowTemplateLiterals 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)
type SlashCommand = `/${string}`

Pass

// with allowTemplateLiterals: true (default)
type SlashCommand = `/${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

[JoshuaKGoldberg]

👍 this makes sense, as a more restrictive option alternative to allowAliases.

[Josh-Cena]

This rule is now deprecated and we won't be adding new options.