这里的所有答案都建议禁用整个eslint规则，这不是很实用，更好的解决方案是忽略该特定位置的eslint错误，如下所示：

// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore

您可以停止使用@ts-ignore
或者您可以禁用eslint规则。将其添加到eslint配置中（.eslintrc或等效配置）

...
  "rules": {
    "@typescript-eslint/ban-ts-ignore": "off"
  }
...

**编辑：**如果您使用的是@typescript-eslint/eslint-plugin版本2.18或更高版本，则规则名为ban-ts-comment，您需要添加

"@typescript-eslint/ban-ts-comment": "off"

这是我的第一次。

因为我缺乏声誉，所以作为一个答案而不是对接受的答案发表评论。我仍然想做出贡献，并可能帮助别人。
对我来说，

@typescript-eslint/ban-ts-comment

不是ban-ts-ignore

我建议允许@ts-ignore使用强制描述。在.eslintrc.js中，可以通过以下配置来实现。链接到文档

rules: {
  '@typescript-eslint/ban-ts-comment': [
    'error',
    {'ts-ignore': 'allow-with-description'},
  ],
},

现在需要为ignore添加一个description。这是通过在ignore语句后添加一个冒号:并添加描述来完成的（这也可以强制执行 min length minimumDescriptionLength）。
范例：

// @ts-ignore: Testing invalid input

在本例中，描述为Testing invalid input

如果使用npm运行应用程序，则可以在package.json中指定规则。语法与其他答案有很大不同：

"eslintConfig": {
    . . .
    "rules": {
      "ban-ts-comment": 0
    },
    . . .
 }

我确认使用ban-ts-comment而不是ban-ts-ignore（仅使用typescript-eslint/eslint-plugin v2.33.0进行测试）

从TypeScript 3.9开始，可以使用@ts-expect-error。
当一行前面有// @ts-expect-error注解时，TypeScript将禁止报告该错误;但是如果没有错误，TypeScript会报告// @ts-expect-error是不必要的。
@typescript-eslint/ban-ts-comment规则默认情况下允许这种注解，只要提供解释原因的描述即可。
举例来说：

// @ts-expect-error: No declaration file for module
import something from 'somemodule';

顺便说一句，如果确实没有类型定义可以从Definitely Typed安装（例如，@types/module_name），那么您可以在项目中的任何.d.ts文件中声明该模块以抑制错误。

declare module 'module_name';