需要这个大声笑

此功能的当前用例是处理空格的单元测试。 我们有充分的理由在我们的代码库中启用了“无尾随空格”规则，但无法在块级别上压倒它意味着我们无法使用 ES6 模板字符串轻松测试尾随空格和回车符.

我在 mathjs 中使用自定义捆绑 _ a.k.a partial import _ 的用例之一

// tslint:disable:no-var-requires
import core from 'mathjs/core'

// @ts-ignore
import mathUnit from 'mathjs/lib/type/unit'
// @ts-ignore
import mathExpression from 'mathjs/lib/expression/function'
// @ts-ignore
import mathArithmatic from 'mathjs/lib/function/arithmetic'


const math = core.create()
// math.import(require('mathjs/lib/type/unit'))
// math.import(require('mathjs/lib/expression/function')) // compile, eval
// math.import(require('mathjs/lib/function/arithmetic')) // basic arithmetic like divide, exponent, etc

math.import(mathUnit)
math.import(mathExpression) // compile, eval
math.import(mathArithmatic) // basic arithmetic like divide, exponent, etc

export const unit = math.unit
export const createUnit = math.createUnit
export const compile = math.compile

我想忽略整个文件的错误。 我继承了一些 ES6 JS 代码，我想转译为 ES5，但目前必须使用 Babel。 将文件重命名为 .ts 并使用 TS 进行编译会很好。

@ptallett您可以使用allowJs编译.js文件并将其包含在编译中。 默认情况下，我们不会在.js文件上发出错误，除非文件顶部有// @ts-check注释，或者您打开了checkJs 。

我仍然会喜欢这个功能，我坐在一个测试文件中，它具有扩展名 .ts，所以我可以导入并轻松查看哪些参数在哪里，并将它编译到 src 文件旁边的目录对我的用例来说非常棒.

我的大部分行现在都是红色的，因为我故意尝试排除一些参数，或者为函数提供与最初需要不同的类型，并期望抛出错误，因为我也在运行时检查它。

如果到处都没有一堆红线，那就太好了。 :)

是否有任何更新，或者有没有人找到一些这样做的好方法？

在 TypeScript 中使用lodash和尤其是lodash/fp非常痛苦，即使使用最新版本的lodash和@types/lodash ，您最终也会收到非常神秘的错误消息。

如果我们可以有一个@ts-ignore-block来忽略下一个块的错误，那么对于像这样的用例来说会很棒_你知道你在做什么_ :-)

我正在使用具有大量全局范围变量的遗留代码，并且在每一行上编写@ts-ignore 变得乏味，对此有任何更新吗？

还寻求有关此请求的更新。 谢谢！

这对于我正在做的事情也非常重要（即类型检查生成的 Vue 模板渲染函数，这需要禁用对代码块的特定检查。）
除了这个问题，#19139 也非常重要，因为尤其是在应用到大部分代码时，您只想禁用特定的检查。

通过抑制孔文件，可以将其添加到编辑器中，例如 vs 代码以保存在工作区设置等中。

也需要这个。 我正在使用graphql-code-generator为我的 GraphQL 模式自动生成一个完整的 ts 文件，并且有一个无关的导入触发 noUnusedLocals。

/* tslint: 禁用*/

代码

/* tslint: 启用*/

// @ts-ignore-start
// @ts-ignore-end

可以结合： https ://github.com/Microsoft/TypeScript/issues/19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn这不是 tslint。

有时，当我在移动和重构东西时，我想暂时忽略整个文件（即不编译它），而不用摆弄 CLI 选项。

最快/最简单的是文件顶部的标志：

// @ts-ignore-file

@lonix1您的用例包括：

// @ts-ignore-start
// @ts-ignore-end

您不必使用// @ts-ignore-end部分。 许多 lint 工具都是这样工作的。

@mgol我不想破坏这个线程......但我尝试了你的建议 - 谢谢！ - 它对我不起作用。 我将这些行放在文件的顶部，并在顶部尝试了一条，在底部尝试了另一条。
其他人可以让它工作吗？

@lonix1我的意思是@Blanen的提议也适用于你，我们不需要 TypeScript 来实现// @ts-ignore-start + // @ts-ignore-end和// @ts-ignore-file ，实现// @ts-ignore-start + // @ts-ignore-end就足够了。 这没有实现，这就是为什么这个问题仍然存在。

@DanielRosenwasser这仅在构建期间 ts 文件存储在另一个文件夹中时才有效。 当项目设置为将 js 文件放置在 ts 文件旁边时，它不会。 js 文件也会被“编译”，例如转换为 es5 吗？ 在传输遗留代码时，这真的很有帮助。

需要这个功能。

用例：

TypeORM期望我们创建 DB 实体类，这些实体类的列可能为空，也可能不为空。 许多列（因此）是不可为空的......因此除了在类定义中之外，应该被视为属性无条件地属于某些定义的类型。 但是，Typescript 要求我们将每一列都定义为强类型。 因此，我们最终得到了很多实体，例如：

@Entity('investigation')
export class InvestigationEntity {
    @PrimaryGeneratedColumn('uuid')
    // @ts-ignore TS2564
    public investigationId: string;

    @Column({ type: 'uuid' })
    // @ts-ignore TS2564
    public userId: string;

    @Column({ type: 'jsonb' })
    // @ts-ignore TS2564
    public metadata: IEncryptedJSONContainer;
}

每列都是必需的，并且（因此）肯定包含一个值，但是由于 TypeORM 的工作方式，每个属性都必须以缺少初始化程序的方式定义。 能够为整个类（因此/或文件）抑制这个特定的 ORM 派生/特定问题将非常方便。

@haggholm有什么理由比ts-ignore public metadata!: IEncryptedJSONContainer吗？

@RyanCavanaugh无知！ 我错过了文档中的那个功能。 对不起; 请无视。

我想要做

// @ts-忽略开始
--strick 空检查，针对一个特定文件

这就是使用 typescript 对私有字段和方法进行单元测试的样子。 我有 6 行专门用于忽略代码。 可怕。 让我的眼睛流血。 任何块忽略的解决方法将不胜感激。

it('TestNode_ReconnectionsWorkload', async function () {
    for (let i = 0; i < 1; i++) {
        nodes.push(await Node.NewNode(serverUrl, {
            handlers: {
                active: async function (n: Node) {
                    try {
                        // @ts-ignore
                        if (n.view.Empty()) {
                            // @ts-ignore
                            if (n.conns.Empty() && !n.server) {
                                // @ts-ignore
                                await n.login(n.address);
                            }
                            return;
                        }

                        const data = new flats.Message({
                            // @ts-ignore
                            id: n.id,
                            type: flats.MessageType.Data,
                            data: 'hello world',
                        });

                        const dataBytes = data.toBytes();
                        const dataBase64 = base64.encode(dataBytes);
                        // @ts-ignore
                        const dataSigBytes = await n.sign(dataBytes);
                        const dataSigBase64 = base64.encode(dataSigBytes);

                        // @ts-ignore
                        for (const conn of n.conns.Iter()) {
                            conn.Send(`${dataBase64}.${dataSigBase64}`);
                        }
                    } catch (error) {
                        console.log(error);
                    }
                },
            },
        }));
    }

    for (const node of nodes) {
        await node.Wait();
    }
});

好吧，我正要添加一个新问题，但我想这个问题涵盖了它。

@ts-ignore处理多行和单行导入的方式不同！

仍然有很多 npm 模块没有类型，或者没有 NoImplicitAny 编写，
这会导致“隐式任何”错误，然后将它们导入：

import { a, b } from 'MyNonTypedModule' // <-- Implicit any error

所以我可以使用@ts-ignore：

//@ts-ignore
import { a, b } from 'MyNonTypedModule'

但是当我使用像 Prettier 这样的自动导入和格式化程序时，会发生这种情况：
（由 Prettier 格式化）

//@ts-ignore
import { 
  a, 
  b 
} from 'MyNonTypedModule' // <-- Still (again) getting the Implicit any error

我可以通过以下方式修复它：

import { 
 a, 
 b
//@ts-ignore
 } from 'MyNonTypedModule'

要么

//@ts-ignore-start
import { 
   a, 
   b
} from 'MyNonTypedModule'
//@ts-ignore-end

但随后它开始在单行导入上看起来像这样：

//@ts-ignore-start
import { a } from 'MyNonTypedModule'
//@ts-ignore-end
import { b } from 'SomeTypedModule'
//@ts-ignore-start
import { c } from 'SomeOtherNonTypedModule'
//@ts-ignore-end

所以我必须这样写，因为自动导入和格式会根据从模块导入的元素数量在单行和多行导入之间发生变化。
如果我手动更改导入代码，它真的违背了自动导入的目的。

最好不必在每个导入时都写 ts-ignore-start 和 ts-ignore-end，
所以： //@ts-ignore用于导入（不仅仅是下一行）在我看来是 ts-ignore 应该处理的。 （或其他一些忽略，例如：@ts-ignore-block / @ts-ignore-import）

我需要抑制整个文件中的某些错误：

// @ts-ignore-all TS1206

/*
... rest of the file
*/

同意上述建议// @ts-ignore-start和// @ts-ignore-end注释来处理此线程中提到的用例。

这很好，因为它看起来与当前的// @ts-ignore指令非常相似，并且它允许您忽略文件中的所有错误，而顶部只有// @ts-ignore-start指令。

上述许多建议都有积极的用例。 我提议：

@ts-ignore作为当前行为
@ts-ignore TSxxx [TSxxx ...]抑制特定错误
@ts-ignore-start开始块忽略
@ts-ignore-start TSxxx [TSxxx ...]抑制块的特定错误
@ts-ignore-end结束块
@ts-ignore-all抑制文件其余部分的错误
@ts-ignore-all TSxxx [TSxxx ...]抑制文件其余部分的特定错误

“特定错误”可能包括类似于 tsconfig 中的命名组或用户定义的 TSxxx 错误组。

我不确定嵌套导入模块的忽略块的价值； 我的偏好是在导入的模块文件中显式 ts-ignore 块。 但是在导入第 3 方库时，可能是有原因的，所以我在这里持观望态度。

想要的.tsignore文件

就像.npmignore & .gitignore

应该有忽略块。 我被 puppeteer 框架困住了。 在 puppeteer 中，您有“评估”方法，它允许您在页面上运行任意脚本块。 这个任意脚本块可以包含对页面上可用函数的引用，换句话说，函数引用将在运行时可用。

// @ts-ignore-start
// @ts-ignore-end

在处理大量遗留代码时，这将非常方便，从而减少人们切换到 TypeScript 的痛苦。

关于

// @ts-ignore-start
// @ts-ignore-end

我早些时候提出了这个建议，有点想改变语法。
让它开始-停止或开始-结束
start和end （作为动词）不是反义词，如果它进入打字稿，这将永远困扰我。

这对我来说很酷

// @ts-ignore-begin
// @ts-ignore-end

非常需要的功能。

为什么这仍然不可能？ :-(

我也需要阻止忽略

+1

+1

这事有进一步更新吗？

🙏🏻

如果我们像通常使用 eslint 那样做呢？

/* @ts-disable */

!function(){
  // no ts here!
}()

/* @ts-enable */

如上所述：一旦您生成可能出现未使用的变量的 TS 代码（例如，使用 swagger），您就需要此功能。

+1

没有//@ts-ignore-file就不可能迁移到 TS

所以，没有人注意到不是真的

@RyanCavanaugh社区显然需要这个，有没有解决这个问题的原因？ 谢谢！

我现在正在为此苦苦挣扎，因为我什至无法在没有 Typescript 哭泣和阻止我的渲染的情况下找到一个解决方案来查看它是否可行。

我们目前需要这个功能。

我们正在导入一个公共库，其中包含一些我们不感兴趣的函数的节点类型。所以最好使用 // @ts-ignore 进行单个导入，而不是使用skipLibCheck来忽略所有的库。

最初我喜欢 // @ts-ignore-file 的想法，但 // @ts-ignore 可能会更好地保持一致性。

所以....我打开 #33383 并在打字稿文件中支持//@ts-nocheck 。 现在，我们作为 _TypeScript_ 编译器团队，我们自己并没有真正理解它（没有解决可能的问题，whaaaat！！？！？） - 甚至打字稿中的//@ts-ignore也只是因为我们的手臂被扭曲了有点，所以我们......犹豫......添加进一步的抑制机制。 所以如果你们真的觉得需要这么广泛的抑制机制，如果你们能去那里就好了👍

@weswigham ，虽然这可能不是最重要的功能。 在开发过程中可能会很方便。 就像临时注释几行代码一样，在开发和尝试在其他地方隔离问题时可能会有所帮助。 然而，我想得到一个警告，所以这种做法不会找到实际导致运行时错误的方法。 甚至可能仅启用此功能以进行开发，但会在构建时引发错误。

由于此问题仍被标记为“等待更多反馈”，因此这里还有更多信息：

在快速制作新架构方向的原型时，我希望在 TypeScript 的指导下这样做，以确保新架构能够正常工作。 但是，我想在进行实验时暂时忽略单元测试文件中的类型错误。

在每个文件的顶部添加某种@ts-ignore-注释会很容易。

我第二个@kumar303的需求：在单元测试中，关闭对给定块/文件的一些检查是有益的，因为它将涵盖这些情况的断言。

@weswigham你可以把它放在编译器标志后面。

你可以把它放在编译器标志后面。

不需要 - 它在 3.7 测试版中。

回复： https ://github.com/microsoft/TypeScript/pull/33383： @weswigham太好了，谢谢！ 这里一个强大的用例是暂时忽略文件中的类型检查，因此我建议还发布一个 lint 规则，该规则在忘记删除@ts-nocheck时失败

在 gatsby 上遇到问题，其中静态 graphQL 查询在.jsx文件中有效，但在.tsx文件中无效。 我认为这个提议可能是一个更可接受的解决方法。 （在这里发布 https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5）

嘿！
建议的解决方案是否已实施？

// @ts-忽略开始
// @ts-忽略结束

我认为这将是非常有益的。 我不介意为此工作。

我们在 3.7 中添加了对//@ts-nocheck的支持，以抑制整个文件中的所有错误。 我认为行级和文件级抑制可以包含_大多数_需求而不会大惊小怪。 如果您在已检查的文件中有足够大的块应该未检查，则可能只是禁用对整个文件的检查，或者，如果这令人反感，将未检查的块提取到自己的文件中并禁用对该文件的检查，或者，失败了，用实际问题压制每一行？ ts-ignore应该忽略单个问题，而ts-nocheck应该忽略单个文件 - 基于范围的抑制实际上不会以任何方式映射到特定单元，所以似乎更糟（因为它无法映射到您正在压制的单个问题或根本原因）。 至少没有错误代码特定的抑制，我对基于范围的抑制不是特别满意。

至少，我更喜欢文件顶部的单个抑制（ //@ts-nocheck File is a legacy untyped UMD module concatenated into the build - declarations are pulled from node_modules, so errors here are hopefully meaningless ）或每个坏事（tm）的单个抑制（ //@ts-ignore The TS compiler doesn't support the assignment on the next line because we never declare it, but we provide this for legacy compat ）。 在我的一生中，我无法想出一个令人信服的、有原则的例子，除了“编写多个连续的抑制使我的眼睛流血”，对此我_zero_ 表示同情，因为从根本上说，我们认为您根本不应该在 TypeScript 中使用抑制。 如果是类型问题，您可以排除它（这就是存在any 、转换和速记模块声明的原因）。 如果这是一个语法问题，那么一切都很糟糕，无论如何我们都会被打破，所以抑制不会做任何事情（抑制不会影响解析错误）。

感谢//@ts-nocheck ，但这并不能解决禁用代码块检查的问题：

const $element = document.createElement('iframe')
$element.loading = 'lazy' // Property 'loading' does not exist on type 'HTMLIFrameElement'.

// @ts-nocheck

我有一个有趣的用例。

我们在 Typescript 中构建或拥有 ORM，它使用 acorn 将语句编译到我们的 DDL 中。

要进行 where 查询，我们必须将其传递给作用域变量：

.entities
.include('parent')
.where(m => m.id === this.id, { id: this.entityId })
.toList()

这不起作用仅仅是因为： Property 'id' does not exist on type 'xxx'

如果我将它包装在@ts-ignore-start中，它将像这样正常工作：

// @ts-ignore-start
.where(m => m.id === this.id, { id: this.entityId })
// @ts-ignore-end

但是当格式化出现并开始添加换行符时：

// @ts-ignore-start
.where(m => m.id === this.id || m.id === this.id2, {
  id: this.entityId,
  id2: this.entity2Id
})
// @ts-ignore-end

它不再起作用了。

这不起作用仅仅是因为：

这正是那种类型级别的错误，如果你真的想抑制它，你应该只在访问权限上有一个as any强制转换（或者，在 jsdoc 中， /** <strong i="8">@type</strong> {any} */(expr) ）。

//@ts-nocheck不适用于我的 ts 角度项目，但//@ts-ignore可以。 微软的这个问题始于 2017 年。2017 年！ 哇...

现在3年了，没有解决办法。 毫不奇怪，JavaScript 开发人员可能不想跳到 typescript

// @ts-ignore-start
// @ts-ignore-end

可以结合：#19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn这不是 tslint。

有计划实施吗？

// @ts-nocheck
是目前唯一的选择:(

在此处添加另一个用例以供考虑...

我是从允许一些基本控制流和条件的内部标记语言生成一堆 TypeScript 代码的代码。 虽然我控制代码生成行为，但我不控制传递给代码生成器的输入（这取决于最终用户）

结果，生成的代码可能很容易具有无法访问的代码，或者在一种情况下是 TS2367，因为可能存在嵌套代码，它根据枚举常量测试一个值，然后在该块内包含对该变量与另一个枚举常量的另一次检查。 例如：

if (foo === MyEnum.ONE) {
  const bar = (foo === MyEnum.TWO ? "two" : "one");
}

使用手写代码，这种模式很容易修复和避免。 然而，通过代码生成，我的用户（开发人员，你知道类型！）不提供不必要地测试不可能值的输入。

我不希望完全禁用类型检查，但由于此错误，我没有其他机制来使用代码生成的代码。 理想情况下，我会为所有代码生成的文件抑制这一错误，但保留所有其他类型检查。

事实上，除了关闭所有类型检查之外，我没有其他解决方案。 在这一点上，我没有从 TypeScript 和纯 JavaScript 中获得太多价值

你是认真的吗？ 这仍然是一个悬而未决的问题，没有在 TS4 中实现？ 🤦🏽

@ivnnv您可以在 TS 3.9 中使用// @ts-expect-error ，请参见此处

@ndraiman @ts-expect-error适用于单个行但不适用于blocks ，因此如果想要“忽略一个块”，仍然需要放置其中的许多行

这里有一些更多的反馈给你：

你还需要什么？ 社区必须做什么才能获得此功能？

最好的用例是在每个正在制作的类型上编写any的替代方法。 您可能对美学没有同情心（这无疑会影响情绪和生产力），但只要有一个符合共同期望的替代方案应该不难接受。

人们对什么可以接受什么不可以有不同的看法。

对某些人来说，这太耗时了，并且限制了人们在做诸如移植代码之类的平凡事情时可以处于的流动状态。
我发现我不能有一个被忽略的代码块而不得不用any强制转换乱扔它，这通常会对可读性产生不利影响（直到存在正确的类型），这让我感到很烦和奇怪。 不得不不断写新评论或沉迷于分心_只是因为有人没有看到忽略代码块的好处_在我看来是不行的。

例子：

一个是将一个项目从 JS 移植到 TS，另一个项目是由第三方开发的。

移植项目中遵循的语法和规则可以是旧的，例如 es2015，也可以是不推荐使用的，以支持更清晰的语法和更少的代码等。

在移植这个项目时，一些代码可能非常容易移植到 TypeScript。 尽管如此，人们还是不可避免地会遇到，例如，对具有任意行为的布尔值和函数进行半思考，这些行为要么需要更多上下文，要么必须考虑一段时间才能创建其类型。

在修复文件时停止检查文件中的函数或代码块真是太棒了。 忽略代码块将使人们能够在他们知道和熟悉的领域快速移动，并保存某些部分以备后用。

当我必须将 JavaScript 移植到 TypeScript 时我的工作流程（而且代码很糟糕）：

1. 将代码从 .js 复制到 .ts 文件。
2. 看看 TS 是否可以通过使用来推断任何类型
3. 从使用中手动了解类型
4. 意识到错误是我存在的祸根
5. 尝试注释掉错误，从而有时会提高文件中的行数 x3 ESLlint + TS（越多越好？）
6. 删除并在顶部添加// @ts-check ，同时仔细编辑其余文件并添加更多类型。

如果我们可以忽略块：

1. 将代码从 .js 复制到 .ts
2. 看看 TS 是否可以通过使用来推断任何类型
3. 从使用中手动了解类型
4. // @ts-ignore-enable ... // @ts-ignore-disable单个函数和麻烦的代码块
5. 当我到达它们并添加类型时取消注释块

自己决定什么是最合理的。 将 JS 移植到具有更多 ESLint 规则的项目时也是如此，并且您必须重构大多数内容。

我希望我们能像在 ESLint 中那样做，并在 TypeScript 中使用/* eslint:disable */ ... /* eslint:enable */ 。

PS 我刚刚在查看此评论时意识到，我已经花了 20 分钟以上的时间试图获得自 2017 年以来我（和许多其他人）一直在寻求的体验，只是为了评论一个即将发布的 3 岁问题。

@weswigham @RyanCavanaugh

提醒：+1：

将给予长子以换取这个

@agusterodin你的牺牲引起了邪恶的注意.....

好吧，事实上什么也没发生，除了我只是给一个简单的 PR :)

但是，就个人而言，我非常同意 TS 团队的意见——这个功能是邪恶的，你应该尽量避免使用@ts-ignore ，不要使用@ts-ignore-enable （或@ts-ignore-start ， 任何）。
但有时，你知道，谚语说drinking posion to satisfie thirst ，我知道这是一个糟糕的选择，但它正是需要的。

编辑：添加解释和示例。
这个 PR 添加了两个指令ts-ignore-enable和ts-ignore-disable 。

1. 如果只使用 ts-ignore-enable，则其余部分都将被忽略。

...   <-- this is normal
// @ts-ignore-enable
XXX    <-- this is ignored
...    <-- this is ignored

1. 您可以多次添加相同的指令，但它们只能工作一次。

// @ts-ignore-enable
XXX  <-- this is ignored  
// @ts-ignore-enable       <-- you could remove this line.
YYY   <-- this is ignored
// @ts-ignore-disable
ZZZ   <-- this is normal
// @ts-ignore-disable      <-- you could remove this line.

1. // @ts-ignore-disable可以单独使用，不会发生任何事情。

2. @ts-expect-error在被忽略的区域中不起作用

// @ts-ignore-enable
XXX  <-- this is ignored
// @ts-expect-error       <-- No error message. whatever next line has error or not.
YYY   <-- this is ignored

1. 没有地区标签，它们只是评论。

// @ts-ignore-enable A
XXX  <-- this is ignored  
// @ts-ignore-enable   B    <-- you could remove this line.
YYY   <-- this is ignored 
// @ts-ignore-disable B
ZZZ   <-- this is normal
// @ts-ignore-disable A     <-- you could remove this line.

在一个完美的世界里，我们不需要忽略类型安全，对吧？ :sweat_smile:
我在复制出色的作品时需要它，例如示例和开场白，甚至是偶尔没有按我想要的方式输入或输入的 SO 答案。 主要是在我的类型安全代码中遵循我的设置。 我只是使用非常严格的设置，因此经常不得不重写一个函数或一些逻辑。 这不是因为我想继续忽略那段代码，那是没有意义的。

忽略代码块是一种方便，对我来说，这似乎是完全合理的，因为我仍然可以@ts-ignore块中的每一行。

我理解这可能对人们去I'll just ignore this because it's easier产生的影响。 正如我所看到的，任何可以使用块范围忽略drink poison to satisfy their thirst的人都已经在用@ts-ignore喝毒药了。

现在您可以在.ts文件中执行@ts-nocheck ，我建议在.ts文件中也允许@ts-check以便我们可以关闭/打开类型检查器：

import fs from 'fs'

fs.readFileSync(32423) // type checking

// @ts-nocheck
fs.foobarbaz() // type checking is off
fs.__randomThing()

// @ts-check
fs.readFileSync(123) // now type checking again

这不需要定义什么是“代码块”。 您可以从 - 到任何行开始和停止类型检查。

更新我弄错了，请参阅https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095 进行更正。

在尝试将使用styled-components的应用程序迁移到 TypeScript 时，我遇到了一个问题，即@ts-ignore不能在模板字符串上方使用（出于某种原因）。 它可以通过忽略块来解决。

我试图忽略的 TS 错误示例：

import styled from "styled-components";
import { Button } from "...";

// @ts-ignore here does not work
const StyledNavBar = styled.div`
  ${Button} {
    margin: auto 0;
  }
`;

作为一个额外的说明：我不能在我的 TS 项目中转换任何类型，我不允许任何类型。 那有什么推荐呢？

@weswigham您对流动状态和美学背景下的生产力有何看法？ 看来你对流血的眼睛没有任何同情心； 但是您对生产力、移植代码和我描述的流程有任何概念吗？ 在考虑了我的评论之后，并且在提高生产力的背景下，您仍然没有看到任何好处吗？ 我还描述了一些需要忽略块作用域的实际情况。 此外，这个功能与 ESLint 以及我们期望的功能相比有何不同？

科学证明，更少的中断可以提高生产力并提高效率； 忽略块作用域可以减少移植代码时的中断。 TS 团队是否没有意识到“从根本上说，我们认为您根本不应该在 TypeScript 中使用抑制功能。” 是一种基于活生生的 TypeScript 的观点，在现实世界中，人们需要将编写不佳的代码移植到其他代码库，具有更多的类型安全性和其他 linting 规则； 在这些情况下，您可以忽略文件或行，但不能忽略刚刚导入的代码块，这是没有意义的。

在我看来，你似乎是在追求乌托邦，而忽略了现实。 @sandersn你没有解决我的任何观点，并且对案件中的新讨论持有旧的回应。 您还声明除非团队另有决定，否则不应实施，在这种情况下：关闭问题？

团队要么需要做出决定，要么需要实现一个明确想要的功能。

把这个问题搁置一旁没有任何意义。

很抱歉，我们无法为您提供所需的最终确定性，但现实情况是“也许以后”是您必须学会接受的答案。 任何给定的功能都不能在明天匆忙地添加到产品中，对于我们设计参数范围内的功能，目前有数千个开放的建议正在竞争我们以符合人体工程学的方式将它们添加到产品中的能力，有用、稳定、有远见。

我们根据当前的反馈、当前解决方案和解决方法的状态、这些场景的优势、工具和其他一百个因素对事物进行优先级排序。 现在不是高优先级的事情可以在以后成为高优先级。 这就是“也许以后”的本质，我认为这是该建议所处位置的准确代表。 目前，这里的决定是继续监控反馈并了解人们遇到的可能需要此功能的优先级高于我们接下来可能添加的任何其他功能，其中有数百个争夺注意力。

这里的语气诚实地倾向于敌对和个人说话，被推向最后通牒不利于建设性的对话，帮助我们了解与替代方案相比，它在哪里增加了超过其复杂性的价值。

我很抱歉设置最后通牒。 看到公关活动让我很生气，但在这个问题上却没有。 我同意我之前的评论没有任何建设性的贡献。

我可以接受这个问题可能需要等待。 我提供了一些反馈，并询问了需要哪些其他反馈才能更接近解决方案，但我没有得到任何回应。 看起来，无论多么烦人，我的相当不具建设性的评论是我需要做的才能得到团队的_some_响应。

似乎仍然没有实际进展到一个有 700 多个积极反应的问题，即几年前，已经取得了进展。 我不认为它应该更快，但似乎团队对探索此功能不感兴趣，因为成员对此有个人意见。 我完全理解所有这些事情。 不过，这不是我要说的。 我想进行一些对话，但我被忽略了。

我想知道我的反馈被考虑了，并且考虑到它的性质，得到了回应。 这不是对功能集的大破坏，活跃的公关在很短的时间内就得到了证明。 一切都准备就绪，人们一直对使用块忽略功能解决此问题做出积极反应，我插话询问社区必须做什么才能获得此功能。 我强烈不同意团队提出的一些观点并反对它，提出了公关并发表评论说“除非我们改变主意” ，否则什么都不会改变。

这就是我的挫败感浮出水面的地方。 你想忽略一个现成的功能，因为团队成员的决定没有改变，完全无视我自己和其他人的反馈。

似乎除非团队中的某个人_根据他们的协议_另有决定，否则我们不会在这个问题上看到任何变化。 这并不需要社区提供更多反馈，不是吗？ 这就是我错误地发出最后通牒的原因。

我对@weswigham的观点提出了几个论据，提供了一些例子，老实说，我仍在等待某种回应。 唯一似乎有帮助的是明显的不安和不具建设性。

我们如何从这里搬走？ 团队希望得到什么反馈？ 这似乎是一个隐藏在“我们根据当前反馈、当前解决方案和解决方法的状态、这些场景的优势、工具以及其他一百个因素来确定优先级”的个人问题。 因为有几个人尝试提供反馈，但团队_根本_没有回应。

我想重申，我理解如果我们将人们的意见从这个主题中移开，这可能不是一个高度优先事项。 同时，该功能已准备好实施，并且已经提出了论据。 现在需要的是团队做出决定/响应（不一定要实施任何事情）并将其公开。 如果这不是必需的，那么请告诉我是什么，或者如何帮助提高 TypeScript 的 _any_ 功能或问题的优先级，尤其是这个。

多行 ( @ts-ignore-start+@ts-ignore-end ) 或内联 (如/* @ts-ignore */ ) @ts-ignore的另一个用例。
环境：

• "noUnusedParameters": true
• 启用 ESLint require-jsdoc规则。
• 类似于以下的代码（简化示例）：

type Data = Record<string, unknown>;
type PrepareSettings = Record<string, unknown>;

/**
 * This is base class that will be inherited.
 */
class SuperClass {
    /**
     * Prepare data for further usage.
     * 
     * <strong i="16">@param</strong> data
     *      Data that should be prepared.
     * <strong i="17">@param</strong> settings
     *      Operation settings.
     */
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {
        return data;
    }

    // Some additional methods...
}

对于所描述的情况，TypeScript 发出以下警告： 'settings' is declared but its value is never read.(6133) 。
可以通过在文档注释末尾添加@ts-ignore来抑制警告：

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {

但在那之后 ESLint 会抱怨Missing JSDoc comment 。
所以解决方案是：

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {   // eslint-disable-line require-jsdoc

这是尴尬和丑陋的。

@RyanCavanaugh @weswigham @sandersn

每月提醒一下，这是社区希望与 TypeScript 团队进一步讨论的内容。 有很多支持，目前缺少的是团队的回应。 我知道有很多预谋，推进 TypeScript 绝非易事。 事情需要时间。 由于没有回应我们如何进一步推进这个建议并采取更直接的行动，我会定期做这样的提醒。 在做出决定之前我不会放弃，并且评论似乎会产生影响（尽管主要是在成为 !@# 时）。

这些年过去了，虽然我本来很害怕这个功能怎么没有，但我个人重新考虑了一下......当有一大堆@ts-ignore时，你可能已经知道有问题了使用您的代码，并花一些时间来改进您的类型。 有时我们都非常懒惰，并且总体上想要速度，但目前通常更容易找出几个合适的类型，而不是将多个@ts-ignore复制粘贴到一大堆代码中。 如果这种不方便的平衡被打破，我们中的许多人将方便地滥用@ts-ignore-enable，这可能只会降低所有小型开源项目的整体质量。

顺便说一句，尽管我们看到在这个问题上有很多 👍 的反应， - 这可能是有偏见的，因为更多的人可能会在没有这个功能的情况下感觉完全没有这个功能而保持沉默，因为他们不在这里。

@JerryGreen参考我以前的评论，我说了同样的话。 此外，人们已经在使用忽略功能进行此操作。 在声称应该有_none_的同时，没有理由一直实施一点毒药。

删除@ts-ignore功能或使其完全成熟。 这样做有很多论据，编写糟糕代码的人将继续使用@ts-ignore ，这与块忽略功能一样糟糕，它们完全相同 - 除了块忽略在视觉上的破坏性较小。

社区仍然需要 TypeScript 团队的回应。

@JerryGreen参考我以前的评论，我说了同样的话。 此外，人们已经在使用忽略功能进行此操作。 在声称应该有_none_的同时，没有理由一直实施一点毒药。

删除@ts-ignore功能或使其完全成熟。 这样做有很多论据，编写糟糕代码的人将继续使用@ts-ignore ，这与块忽略功能一样糟糕，它们完全相同 - 除了块忽略在视觉上的破坏性较小。

社区仍然需要 TypeScript 团队的回应。

一些特殊场景还是需要使用@TS忽略。 例如，CDN 导入不依赖于 node_ 。 模块场景中不存在 TS 文件

@L-Hknu 感谢您的澄清。 人们使用它就像他们使用 ESLint 的忽略一样。

除了功能需要之外，忽略功能在上下文中是不允许的。 这告诉我可以使用它来忽略代码。

我仍然无法解释为什么不应该忽略块，因为它大多数时候都以相同的方式使用。

对于一些开源代码，我已经放弃了转换为类型，因为转换的进度对于块忽略会更舒服。 我不需要它，但我认为很多人会通过打字进入门内； 此外，许多人很可能会更有效地为转换做出贡献，尤其是考虑到块和每行评论之间的美学差异很大。

我对这个实现的最大用例是不支持打字稿的第三方包，我需要忽略它的一些用途。

@L-Hknu 感谢您的澄清。 人们使用它就像他们使用 ESLint 的忽略一样。

除了功能需要之外，忽略功能在上下文中是不允许的。 这告诉我可以使用它来忽略代码。

我仍然无法解释为什么不应该忽略块，因为它大多数时候都以相同的方式使用。

对于一些开源代码，我已经放弃了转换为类型，因为转换的进度对于块忽略会更舒服。 我不需要它，但我认为很多人会通过打字进入门内； 此外，许多人很可能会更有效地为转换做出贡献，尤其是考虑到块和每行评论之间的美学差异很大。

看起来已经完成了
#40267