Всем уже давно понятно, что вместо директивы @ts-ignore
следует использовать директиву @ts-expect-error
. Пригождается она даже самым квалифицированным и педантичным разработчикам, например, чтобы временно заглушить ложную ошибку типов из кривого @types/*
пакета.
Однако, далеко не все знают, что обе директивы одинаково опасны, если использовать их неосторожно, ведь заглушить ими можно не только ошибки типов, но и откровенно невалидный синтаксис, который гарантированно приведет к выбросу исключения в рантайме.
Убедимся на реальном примере:
declare const obj: {
prop?: {
innerProp: string;
}
}
// @ts-expect-error
obj.prop?.innerProp = 'hello, world'
Спокойно компилируется через TypeScript v5.4.5 со строжайшим конфигом, однако в рантайме нас неминуемо ждет Uncaught SyntaxError: Invalid left-hand side in assignment
. И я видел такой код, в проде, причем исключение это проглатывалось, делая эту дичайшую ошибку по сути невидимой, пока не запустишь дебаггер.
На самом деле ухищряться особо не нужно — компилятор считает, что директива уместна даже в случае присвоения значения к примитиву
// @ts-ignore
'LHS' = 'RHS'
Но мы-то теперь знаем, что здесь будет в рантайме — очередное исключение Uncaught SyntaxError: Invalid left-hand side in assignment
.
Следует отметить, что ошибки вроде TS1177, TS1489 и некоторые другие, оверрайдят обе директивы и не позволяют программисту уйти в полный игнор.
Надеюсь, в будущем это поведение будет как-то унифицировано и все очевидно критические ошибки будут оверрайдить обе директивы, а пока остается только помнить об ответственности, связанной с использованием этих этой директивы.
Комментарии (4)
adminNiochen
22.05.2024 18:59Вообще если в какой-то библиотеке кривая типизация - правильнее будет исправить типы, чем расставлять игноры по коду
Aquahawk
6 лет назад было предложение уметь указывать код ожидаемой ошибки https://github.com/microsoft/TypeScript/issues/19139, я даже pull request делал, однако так и не приняли.
semyonf Автор
Видел это, ага, было бы совсем хорошо иметь такую возможность