Игнорировать определенные ошибки компиляции TypeScript?

Конкретная проблема автора с this кажется решенной, но возникает вопрос об игнорировании ошибок и для тех, кто попадает сюда и ищет, как игнорировать ошибки:

Если правильно исправить ошибку или использовать более достойные обходные пути, подобные уже предложенным здесь, не вариант, начиная с TypeScript 2.6 (выпущенного 31 октября 2017 г.), теперь существует способ игнорировать все ошибки из определенного строка, используя // @ts-ignore комментарии перед целевой строкой.

Исправленная документация достаточно лаконична, но резюмирую:

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

отключает отчеты об ошибках для этой строки.

Однако это следует использовать только в крайнем случае, когда исправление ошибки или использование таких хаков, как (x as any), гораздо сложнее, чем потеря всей проверки типов для строки.

Что касается указания определенных ошибок, текущее состояние (середина 2018 г.) обсуждается здесь, в Примечаниях к совещанию разработчиков ( 16.02.2018) и дальнейшие комментарии, что в основном

"без вывода пока"

и сильное сопротивление введению этой тонкой настройки.

Я думаю, что ваш вопрос в том виде, в каком он задан, является проблемой XY. Вы собираетесь как я могу гарантировать, что некоторые из моих методов класса гарантированно будут иметь правильный this контекст?

Для этой проблемы я бы предложил следующее решение:

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

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

Это дает несколько преимуществ.

Во-первых, вы открыто говорите о том, что происходит. Большинство программистов, вероятно, не поймут тонкую семантику того, в чем разница между синтаксисом члена и метода с точки зрения генерации кода.

Во-вторых, он очень ясно дает понять, глядя на конструктор, какие методы будут иметь гарантированный this контекст. Критически важно, с точки зрения производительности, вы не хотите писать так все свои методы, а только те, которые в этом абсолютно необходимы.

Наконец, он сохраняет семантику ООП класса. Фактически вы сможете использовать super.DoSomething из реализации производного класса DoSomething.

Я уверен, что вам известна стандартная форма определения функции без обозначения стрелок. Есть еще одно выражение TypeScript, которое генерирует точно такой же код, но без ошибки компиляции:

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

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

Так почему это законно, а другое - нет? Хорошо по спецификации: an arrow function expression preserves the this of its enclosing context. Таким образом, он сохраняет значение this из объявленной области. Но объявление функции на уровне класса this на самом деле не имеет смысла.

Вот пример, который неверен по той же причине, которая может быть более ясной:

class LambdaMethods {
    private message: string;

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

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

То, как инициализатор работает в сочетании с конструктором, является деталью реализации, на которую нельзя полагаться. Это могло измениться.

Я уверен, что со временем появится хороший способ управлять этим ключевым словом, но в настоящее время я считаю это довольно ужасным.

Одна из высокоуровневых целей (которую я люблю) в TypeScript - это расширение языка JavaScript и работа с ним, а не борьба с ним. Как работает this, сложно, но стоит изучить.