[restrict-template-expressions] Invalid type "never" of template literal expression

[carlpett]

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have read the FAQ and my problem is not listed.

Repro

From the official TS docs on union exhaustiveness checks:

interface NetworkLoadingState {
  state: 'loading'
}

interface NetworkFailedState {
  state: 'failed'
  code: number
}

interface NetworkSuccessState {
  state: 'success'
  response: {
    title: string
    duration: number
    summary: string
  }
}

type NetworkState =
  | NetworkLoadingState
  | NetworkFailedState
  | NetworkSuccessState

function assertNever (x: never): never {
  throw new Error(`Unexpected object: ${x}`)
}

function logger (s: NetworkState): string {
  switch (s.state) {
    case 'loading':
      return 'loading request'
    case 'failed':
      return `failed with code ${s.code}`
    case 'success':
      return 'got response'
    default:
      return assertNever(s)
  }
}

Expected Result

A pass? Or something helpful about what to do instead?

Actual Result

repro.ts:25:41: Invalid type "never" of template literal expression. (@typescript-eslint/restrict-template-expressions)

Additional info
Running via ts-standard

Versions

package	version
@typescript-eslint/eslint-plugin	4.14.1
@typescript-eslint/parser	4.14.1
TypeScript	4.1.3
ESLint	7.19.0
node	v14.15.5

[bradzacher]

This is intentional.
never is not known to be "string-like".
You'll get exactly the same result with unknown.

If you want to use this pattern, then use a disable comment.

[carlpett]

In this case the never is on the NetworkState type, but I assume that doesn't really is the point?
And sorry if this is the wrong place to ask, is there a "better" pattern for exhaustive checks?

[bradzacher]

In this case the never is on the NetworkState type

What type a variable was before doesn't matter - all that matters is that in that branch TS thinks that it should be unreachable, and thus assigns it type never.

is there a "better" pattern for exhaustive checks

No. This is the correct pattern.

But if you want to throw errors with template strings whilst using restrict-template-expressions then you'll run into this problem. Just use a disable comment.