忽略某些 TypeScript 编译错误？

Ignore certain TypeScript compile errors?

提问by Grofit

I am wondering if there is a way to ignore certain TypeScript errors upon compilation?

我想知道是否有办法在编译时忽略某些 TypeScript 错误？

I basically have the same issues most people with large projects have around using the thiskeyword, and I don't want to put all my classes methods into the constructor.

我基本上遇到了大多数大型项目人在使用this关键字时遇到的相同问题，而且我不想将我所有的类方法都放入构造函数中。

So I have got an example like so:

所以我有一个这样的例子：

TypeScript Example

打字稿示例

Which seems to create perfectly valid JS and allows me to get around the thiskeyword issue, however as you can see in the example the typescript compiler tells me that I cannot compile that code as the keyword this is not valid within that scope. However I don't see why it is an error as it produces okay code.

这似乎创建了完全有效的 JS 并允许我绕过this关键字问题，但是正如您在示例中看到的那样，打字稿编译器告诉我我无法编译该代码，因为关键字 this 在该范围内无效。但是我不明白为什么它是一个错误，因为它产生了好的代码。

So is there a way to tell it to ignore certain errors? I am sure given time there will be a nice way to manage the thiskeyword, but currently I find it pretty dire.

那么有没有办法告诉它忽略某些错误？我相信给定时间会有一个很好的方法来管理this关键字，但目前我发现它非常可怕。

== Edit ==

== 编辑 ==

(Do not read unless you care about context of this question and partial rant)

（除非你关心这个问题的上下文和部分咆哮，否则不要阅读）

Just to add some context to all this to show that I'm not just some nut-job (I am sure a lot of you will still think I am) and that I have some good reasons why I want to be able to allow these errors to go through.

只是为所有这些添加一些背景，以表明我不仅仅是一些疯狂的工作（我相信你们中的很多人仍然认为我是）而且我有一些很好的理由为什么我希望能够允许这些要通过的错误。

Here are some previous questions I have made which highlight some major problems (imo) with TypeScript currentthisimplementation.

以下是我之前提出的一些问题，它们突出了 TypeScript当前此实现的一些主要问题 (imo) 。

Using lawnchair with Typescript

在 Typescript 中使用草坪椅

Issue with child scoping of this in Typescript

在打字稿中对此进行子范围界定的问题

https://typescript.codeplex.com/discussions/429350(And some comments I make down the bottom)

https://typescript.codeplex.com/discussions/429350（我在底部做了一些评论）

The underlying problem I have is that I need to guarantee that all logic is within a consistent scope, I need to be able to access things within knockout, jQuery etc and the local instance of a class. I used to do this with the var self = this;within the class declaration in JavaScript and worked great. As mentioned in some of these previous questions I cannot do that now, so the only way I can guarantee the scope is to use lambda methods, and the only way I can define one of these as a method within a class is within the constructor, and this part is HEAVILY down to personal preference, but I find it horrific that people seem to think that using that syntax is classed as a recommended pattern and not just a work around.

我的潜在问题是我需要保证所有逻辑都在一致的范围内，我需要能够访问淘汰赛、jQuery 等和类的本地实例中的内容。我曾经使用var self = this;JavaScript 中的类声明来做到这一点，并且效果很好。正如在前面的一些问题中提到的，我现在不能这样做，所以我可以保证范围的唯一方法是使用 lambda 方法，而我可以将其中一个方法定义为类中的方法的唯一方法是在构造函数中，这部分很大程度上取决于个人喜好，但我发现人们似乎认为使用该语法被归类为推荐模式而不仅仅是一种解决方法，这很可怕。

I know TypeScript is in alpha phase and a lot will change, and I HOPE so much that we get some nicer way to deal with thisbut currently I either make everything a huge mess just to get typescript working (and this is within Hundreds of files which I'm migrating over to TypeScript ) or I just make the call that I know better than the compiler in this case (VERY DANGEROUS I KNOW) so I can keep my code nice and hopefully when a better pattern comes out for handling this I can migrate it then.

我知道 TypeScript 处于 alpha 阶段，很多都会改变，我非常希望我们能找到更好的方法来处理这个问题，但目前我要么把所有东西都弄得一团糟，只是为了让 typescript 工作（这是在数百个文件中）我正在迁移到 TypeScript ）或者我只是在这种情况下调用我比编译器更了解的调用（我知道非常危险）所以我可以保持我的代码很好，希望当出现更好的模式来处理这个我然后可以迁移它。

Also just on a side note I know a lot of people are loving the fact that TypeScript is embracing and trying to stay as close to the new JavaScript features and known syntax as possible which is great, but typescript is NOT the next version of JavaScript so I don't see a problem with adding some syntactic sugar to the language as people who want to use the latest and greatest official JavaScript implementation can still do so.

另外顺便提一下，我知道很多人都喜欢 TypeScript 正在接受并试图尽可能接近新的 JavaScript 功能和已知语法的事实，这很棒，但 typescript 不是 JavaScript 的下一个版本，所以我不认为在语言中添加一些语法糖有问题，因为想要使用最新最好的官方 JavaScript 实现的人仍然可以这样做。

采纳答案by stsloth

The author's specific issue with thisseems to be solved but the question is posed about ignoring errors, and for those who end up here looking how to ignore errors:

作者的具体问题this似乎已经解决，但问题是关于忽略错误，对于那些最终在这里寻找如何忽略错误的人：

If properly fixing the error or using more decent workarounds like already suggested here are not an option, as of TypeScript 2.6 (released on Oct 31, 2017), now there is a way to ignore all errors from a specific lineusing // @ts-ignorecomments before the target line.

如果从 TypeScript 2.6（2017 年 10 月 31 日发布）开始，正确修复错误或使用更像这里建议的更合适的解决方法不是一种选择，现在有一种方法可以使用// @ts-ignore目标之前的注释忽略特定行中的所有错误线。

The mendtioned documentationis succinct enough, but to recap:

提到的文档足够简洁，但要回顾一下：

// @ts-ignore
const s : string = false

disables error reporting for this line.

禁用此行的错误报告。

However, this should only be used as a last resort when fixing the error or using hacks like (x as any)is much more trouble than losing all type checking for a line.

然而，这应该只在修复错误或使用 hacks 时作为最后的手段使用，比如(x as any)比丢失一行的所有类型检查更麻烦。

As for specifying certain errors, the current (mid-2018) state is discussed here, in Design Meeting Notes (2/16/2018) and further comments, which is basically

至于指定某些错误，这里讨论了当前（2018 年中期）的状态，在设计会议笔记（2/16/2018）和进一步的评论中，基本上是

"no conclusion yet"

“没有定论尚”

and strong opposition to introducing this fine tuning.

并且强烈反对引入这种微调。

回答by Ryan Cavanaugh

I think your question as posed is an XY problem. What you're going for is how can I ensure that some of my class methods are guaranteed to have a correct thiscontext?

我认为您提出的问题是XY 问题。您要寻找的是如何确保我的某些类方法具有正确的this上下文？

For that problem, I would propose this solution:

对于这个问题，我会提出这个解决方案：

class LambdaMethods {
    constructor(private message: string) {
        this.DoSomething = this.DoSomething.bind(this);
    }

    public DoSomething() {
        alert(this.message);
    }
}

This has several benefits.

这有几个好处。

First, you're being explicit about what's going on. Most programmers are probably not going to understand the subtle semantics about what the difference between the member and method syntax are in terms of codegen.

首先，你对正在发生的事情很清楚。大多数程序员可能不会理解关于成员和方法语法之间在代码生成方面的区别的微妙语义。

Second, it makes it very clear, from looking at the constructor, which methods are going to have a guaranteed thiscontext. Critically, from a performance, perspective, you don't want to write all your methods this way, just the ones that absolutely need it.

其次，通过查看构造函数，它非常清楚哪些方法将具有有保证的this上下文。至关重要的是，从性能的角度来看，您不想以这种方式编写所有方法，而只想编写绝对需要的方法。

Finally, it preserves the OOP semantics of the class. You'll actually be able to use super.DoSomethingfrom a derived class implementation of DoSomething.

最后，它保留了类的 OOP 语义。您实际上可以super.DoSomething从DoSomething.

回答by Jeffery Grajkowski

I'm sure you're aware of the standard form of defining a function without the arrow notation. There's another TypeScript expression that generates the exact same code but without the compile error:

我相信你知道定义一个没有箭头符号的函数的标准形式。还有另一个 TypeScript 表达式可以生成完全相同的代码，但没有编译错误：

class LambdaMethods {
    private message: string;
    public DoSomething: () => void;

    constructor(message: string) {
        this.message = message;
        this.DoSomething = () => { alert(this.message); };
    }
}

So why is this legal and the other one isn't? Well according to the spec: an arrow function expression preserves the this of its enclosing context. So it preserves the meaning of thisfrom the scope it was declared. But declaring a function at the class level thisdoesn't actually have a meaning.

那么为什么这是合法的而另一个不合法呢？好吧，根据规范：an arrow function expression preserves the this of its enclosing context. 所以它保留了this它声明的范围内的含义。但是在类级别声明一个函数this实际上没有意义。

Here's an example that's wrong for the exact same reason that might be more clear:

这是一个错误的示例，原因完全相同，但可能更清楚：

class LambdaMethods {
    private message: string;

    constructor(message: string) {
        this.message = message;
    }

    var a = this.message;  // can't do this
}

The way that initializer works by being combined with the constructor is an implementation detail that can't be relied upon. It could change.

初始化器与构造器结合的工作方式是一个无法依赖的实现细节。它可以改变。

I am sure given time there will be a nice way to manage the this keyword, but currently I find it pretty dire.

我相信给定时间会有一个很好的方法来管理 this 关键字，但目前我发现它非常可怕。

One of the high-level goals (that I love) in TypeScript is to extend the JavaScript language and work with it, not fight it. How thisoperates is tricky but worth learning.

TypeScript 的高级目标之一（我喜欢）是扩展 JavaScript 语言并使用它，而不是与之抗争。如何this操作是棘手的，但值得学习。