If you are a user of TSLint-to-ESLint this was a bug that has since been fixed so rerunning the script with a newer version would also fix the issue, or just disable the no-shadow and enable @typescript-eslint/no-shadow

If you are using some public config that is misusing the rule then be sure to let them know, the number of people still running into this is somewhat staggering.

see @typescript-eslint/no-shadow how to use also this section of FAQ

How to use

{
  // note you must disable the base rule as it can report incorrect errors
  "no-shadow": "off",
  "@typescript-eslint/no-shadow": ["error"]
}

Searching typescript-eslint GitHub issues shows a number of people asking the same thing.

Tadhg McDonald-Jensen's answer is useful, but there is one thing that needs to be said. Writing the following configuration items directly to .eslintrc will report an error:

{
  // note you must disable the base rule as it can report incorrect errors
  "no-shadow": "off",
  "@typescript-eslint/no-shadow": ["error"]
}

Here's a correct example with the no-shadow rule:

{
  "rules": {
      "no-shadow": "off",
      "@typescript-eslint/no-shadow": ["error"]
  },
}

This error occurs for me when I declared a variable with the some name of the object. I forgot to put the variable name in lowarcase rather than uppercase which the name of the object. like TypeFile: TypeFile

Solution: To fix it just put the variable name in lowercase.

Example of code generating this Eslint error:

This is my Enum: type-file-model.ts

public enum TypeFichier {
XML, PDF, IMAGE, ZIP
}

This is my object model app-file-model.ts

import {TypeFile} from 'app/shared/model/enum/type-file.model';

export interface IAppFile {
  ...
  TypeFile?: TypeFile;
}

export class AppFile implements IAppFile{
  constructor(
    ...
    public TypeFile?: TypeFile
  ) {}
}

It seems like adding this to the base "rules" was not enough and I had to add it again under the overrides

# eslintrc.js
{
  "rules": { // Did not work here as intended
    "@typescript-eslint/dot-notation": "error",
    "no-shadow": "off",
  },
  "overrides": [
    {
      "files": [
          "*.ts"
      ],
      ...
      "rules": { // Here it worked
          "@typescript-eslint/dot-notation": "error",
          "no-shadow": "off",
      }
  ]
}

I had similar issue with the following code in TypeScript:

export enum MyEnum {
  myValueOne = 'myValue',
  myValueTwo = 'myValueTwo', // <-- got "already declared in the upper scope” error
}

export class myValueTwo {
   constructor(){}
}

Unfortunately neither rules or overrides didn't solve issue

 {
   "rules": {
      "no-shadow": "off",
      "@typescript-eslint/no-shadow": ["error"]
   },
   "overrides": {
      "no-shadow": "off",
      "@typescript-eslint/no-shadow": ["error"]
   },
}

After spending few hours checking different Issues, questions and documentation about the problem I came across the official docs of @typescript-eslint/no-shadow. Here is the link

What I had to do is do add additional the ignoreTypeValueShadow options in eslint for @typescript-eslint/no-shadow.

My final setup for no-shadow looks like this:

{
  "overrides": {
    "no-shadow": "off",
    "@typescript-eslint/no-shadow": ["error", , { "ignoreTypeValueShadow": true }]
  },
}

I managed to stop the error from appearing using the following configuration:

{
   "rules": {
      "no-shadow": "off",
      "@typescript-eslint/no-shadow": ["off"]
   }
}

Use "off" for both cases, as I notice a recurring pattern in all the examples I read, which use "off" in the first and "error" in the second. This makes me doubt that it is the correct way to do it, but I have not been able to avoid those errors in another way, not even using overwriting.