+1

Note this came up in discussion before here: #10005 (comment)

and restrict-template-expressions does flag unknown-valued expressions

@typescript-eslint/triage-team

This is actually working by design - the rule purposely ignores any/unknown.

https://github.com/typescript-eslint/typescript-eslint/blob/main/packages%2Feslint-plugin%2Fsrc%2Frules%2Fno-base-to-string.ts#L254-L257

The reason we ignore it is because we cannot reason about the types. Generally we ignore any/unknown in our rules.

I can see that you added tests for this case in #10432 Kirk heh.

I'm personally in favour of always ignoring any/unknown and instead always and relegating the handling of those types to the no-unsafe-* rules.

Hmm, that makes sense for any but wouldn't address unknown though

String(unknown) is very useful in a generic logging context and we can't really reason about its behavior otherwise. What's a good alternative?

String(unknown) is very useful in a generic logging context and we can't really reason about its behavior otherwise. What's a good alternative?

Well, that was basically my question here: #10005 (comment). My understanding of that conversation was that JSON.stringify(x) is what you recommend...?

String(x) works reasonably well for all primitives but not most objects. JSON.stringify(x) works arguably better for some primtiives, but not at all for others, works well for POJOs, but works badly for other objects, regardless of .toString().

Why is String(x) prohibited for null | undefined | boolean | string | number | bigint | symbol | Function | object (due to the inclusion of object) but allowed for unknown? I do think that String(unknown) is quite useful but it feels like it's inconsistent for it to be allowed granted the rest of the rule's behavior.

I can see that you added tests for this case in #10432 Kirk heh.

Lol that is pretty funny 😀. Granted the context, I'm pretty sure that that was more of a descriptive snapshot of relevant codepaths that I wanted to be sure my changes didn't change, rather than a normative belief on my part 😁

For logging functions I like to use a Json type so I can check that the provided value is definitely serializable:

export type Json = boolean | number | string | null | JsonArray | JsonRecord
export interface JsonRecord {
  readonly [key: string]: Json
}
export interface JsonArray extends ReadonlyArray<Json> {}

export const log = (value: Json) => {
  // …
};

log({ toJSON() { throw "Oopsies"; } });

Isn't JavaScript just the best language?

Haha, yeah, I know it's not bulletproof, but I think it strikes a good balance.

String(any) is also caught by no-unsafe-argument. +1 from me on having this rule ignore any.

As for unknown, I could see why someone would want to flag it - and also why others would want to allow it for logging/other purposes. Proposal: how about an opt-in option for flagging unknown?

Accepting PRs for an opt-in option with a name like checkUnknown.