The language and UX around no-unsafe-call (and similar rules) messages indicate "an error type typed value", which seems unclear and maybe also misleading.
Before You File a Bug Report Please Confirm You Have Done The Following...
Playground Link
https://typescript-eslint.io/play/#ts=5.5.2&fileType=.js&code=MYewdgzgLgBApgGxgXhgegFQZgASgTwAc4YBvAUQTgFs4woBfGDNGAClIYEoAoHxAHQALAE5wAZgICWYYAgCuAEzgQ2AcgCGAI2BreQA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Jge1tieQEMAZolpk%2B8eOiiJo0DtEjgwAXxBKgA&tsconfig=&tokens=false
Repro Code
const el = /** @type {Element} */ ({})
el.href.includes('abc')

ESLint Config
module.exports = {
parser: "@typescript-eslint/parser",
rules: {
"@typescript-eslint/<rule-name>": ["error", ...<options>],
},
};
tsconfig
Expected Result
I expected the error message:
Unsafe call of a method on an `any` typed value
Differences:
- mentions the type
any (which is the only observable type in JSDoc without checkJs: true)
- doesn't mention the type
error
- less important: mentions "method"
Actual Result
I observed the error message:
Unsafe call of an `error` type typed value
Confusing parts:
- no mention of
any
- mentions the type
error, which is unobservable in JSDoc without checkJs: true
- also, if I hear "an
error type typed value", then that could sound like something like Error, so even if this "error" language is kept in some form, maybe it should be disambiguated from Error
- less important: does not mention "method"
Using this in TypeScript or with checkJs: true leads to a more understandable experience:

Hovering over href in el.href shows that TypeScript is reporting an error:
Property 'href' does not exist on type 'Element'.
Additional Info
This also affects other rules, since they also create messages the same way.
The type for this seems to be coming from the ts-api-utils function isIntrinsicErrorType
cc @JoshuaKGoldberg
The language and UX around
no-unsafe-call(and similar rules) messages indicate "anerrortype typed value", which seems unclear and maybe also misleading.Before You File a Bug Report Please Confirm You Have Done The Following...
Playground Link
https://typescript-eslint.io/play/#ts=5.5.2&fileType=.js&code=MYewdgzgLgBApgGxgXhgegFQZgASgTwAc4YBvAUQTgFs4woBfGDNGAClIYEoAoHxAHQALAE5wAZgICWYYAgCuAEzgQ2AcgCGAI2BreQA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Jge1tieQEMAZolpk%2B8eOiiJo0DtEjgwAXxBKgA&tsconfig=&tokens=false
Repro Code
ESLint Config
tsconfig
{ "compilerOptions": { } }Expected Result
I expected the error message:
Differences:
any(which is the only observable type in JSDoc withoutcheckJs: true)errorActual Result
I observed the error message:
Confusing parts:
anyerror, which is unobservable in JSDoc withoutcheckJs: trueerrortype typed value", then that could sound like something likeError, so even if this "error" language is kept in some form, maybe it should be disambiguated fromErrorUsing this in TypeScript or with
checkJs: trueleads to a more understandable experience:Hovering over
hrefinel.hrefshows that TypeScript is reporting an error:Additional Info
This also affects other rules, since they also create messages the same way.
The type for this seems to be coming from the
ts-api-utilsfunctionisIntrinsicErrorTypecc @JoshuaKGoldberg