Before You File a Bug Report Please Confirm You Have Done The Following...

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have searched for related issues and found none that matched my issue.
• I have read the FAQ and my problem is not listed.

Playground Link

https://typescript-eslint.io/play#ts=5.3.3&fileType=.tsx&code=KYOwrgtgBA0iD2B3EBlALgQzWAzsHUA3gFBRQDiA8pQCJQC8UA5FbUwDSlQBCAgnYyZ8aHYgF9ixAGZgQAYzQBLeCCgALDCAAmAG2DosuABQ5M2HAC4opgE6KQAcwCUVgG7xFWol0VSoJs1wGekY4JFRAvBwAOlYaJ28yMgB6ZKgteCgHeHgvNDV7By4xKGAdPChff1NDAhDQhGQDc3xo4QSSJKhU9MyAIww8gsdi0vLgRKSe2RtgOXgHewAvYC8a8wBuXqhNeHzgGyh8wtKQJVmdAE9i8SA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Jge1tieQEMAZonpNYAW1pkOY4nyrIOTdFETRoHaJHBgAviB1A&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

Repro Code

enum KnownStatuses {
  GOOD = 'GOOD',
  BAD = 'BAD',
}

function handleStatus(status: string): void {
  if (status === KnownStatuses.GOOD) {
    // do good thing
  } else if (status === KnownStatuses.BAD) {
    // do bad thing
  } else {
    // unrecoginzed status; do another thing entirely
  }
}

ESLint Config

module.exports = {
  "rules": {
    "@typescript-eslint/no-unsafe-enum-comparison": "error"
  }
}

tsconfig

{
  "compilerOptions": {
    "strictNullChecks": true
  }
}

Expected Result

No errors.

Actual Result

Errors on both enum comparisons.

Additional Info

I've just upgraded to typescript-eslint 7 in a new codebase, and I'm coming across dozens of examples of this sort of code that comes from handling network requests. This happened in the previous codebase I worked in as well when I upgraded the linter there as well.

I do not believe there is anything wrong with the example code, and I do not believe that it falls under the purpose of the rule as stated in the docs page.

I did find this closed issue (#7219) which described this pattern as a "niche" usage.... I'm not sure I agree with that assessment granted I've seen it many times in the wild. Furthermore, the reason that I'm opening this, rather than deferring to the closed issue, is that I'd like to make the case that a better solution would be to only compare against unsafe string literals rather than using the type checker to compare against unsafe strings in general.

so

// still error
declare status: KnownStatuses;
if ('GOOD' === status) ...

// not error
declare status: string
if (status === KnownStatuses.GOOD) ...

I believe that would be much more consistent with the doc page's stated explanation and examples. As is, I just disabled the rule in the first codebase I worked in where it got enabled, since none of our errors matched anything in the example on the doc page, so I couldn't really understand why the rule was upset.