Enhancement: [restrict-template-expressions] More permissive type check

[abrahamguo]

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/restrict-template-expressions/

Description

Related: #6279

I have added the allowArray option to restrict-template-expressions in #8389.

Now, I'd like to discuss other things that may be useful to put in a string. The most common case for me is stringifying URLSearchParams, Date and Buffers, but there could be potential for others as well.
Some questions for discussion:

• Do we add a new option ignoredTypeNames? (I have created a draft PR feat: add ignoredTypeNames option for restrict-template-expressions #8556 implementing this)
• What will be the default value for this option?
• What does this mean for the no-base-to-string rule, which is becoming increasingly similar to this rule?

Fail

declare const maybeParams: URLSearchParams | undefined;

fetch(`https://myapi.com?${maybeParams}`);

Pass

declare const definitelyParams: URLSearchParams;

fetch(`https://myapi.com?${definitelyParams}`);

Additional Info

No response

[bradzacher]

Quick response:

Do we add a new option ignoredTypeNames?

Nope. We do not want loose "type name a string" options.
See #6017

TL;DR - if you configure ignoreTypeNames: ["Date"] how does that differentiate between

declare const x: Date;
`${x}` // will result in '<..date time string here..>'

and

interface Date { prop: string }
declare const x: Date;
`${x}` // will result in '[object Object]'

If we add a general purpose option - it needs to follow the same spec as described in #6017 and implemented in the related PRs in other rules.

[abrahamguo]

@bradzacher Does this mean that ignoredTypeNames in no-base-to-string is also on the chopping block to be removed, because of the same issue?

[bradzacher]

At some point in the future - sure. It's just low on the list of list of priorities given its already implemented and would be a large breaking change for users to change.

[abrahamguo]

What do you guys think about the comments on #6279?

(which, really, I don't think should be closed, since it hasn't really been fixed?)

In that issue, it seems like @bradzacher supports such an option.

[JoshuaKGoldberg]

I'm personally in favor of adding the standard format of "allow specifically these types" to restrict-template-expressions (#8722 (comment)). Would like to see more input from @typescript-eslint/triage-team before making any decisions.

[JoshuaKGoldberg]

A 👍 from another team member and a past "I'm ok with adding" from #6279 (comment). Marking as accepting PRs!