Ответ.

История вопроса

TypeScript изначально разрабатывался с возможностью максимально плавного перехода с JavaScript, поэтому по умолчанию переменные или параметры без явно указанного типа получали тип any. Это упрощало миграцию, но снижало преимущества статической типизации. В целях повышения надёжности и предсказуемости кода команда TypeScript внедрила флаг компилятора noImplicitAny, который требует явно указывать типы или давать TypeScript возможность корректно их выводить.

Проблема

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

Решение

Включение noImplicitAny в файле tsconfig.json заставляет компилятор TypeScript выбрасывать ошибку при каждом неявном использовании типа any. Это требует от разработчиков внимательного отношения к типам, делает процессы рефакторинга менее рискованными, а сам код — более надёжным.

Пример кода:

// tsconfig.json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

// Пример функции без указания типа параметраunction printUser(user) {
  console.log(user.name); // Ошибка компиляции, если не указан тип
}

// Корректно:
function printUser(user: { name: string }) {
  console.log(user.name);
}

Ключевые особенности:

Требует явно указывать типы в любых неоднозначных местах.
Позволяет выявлять большую часть ошибок типов на этапе компиляции.
Обеспечивает высокую предсказуемость и безопасность кода на больших проектах.

Вопросы с подвохом.

Включение noImplicitAny всегда предотвращает все потенциальные ошибки типов в проекте?

Нет, этот флаг устраняет только неявные any. Явное использование any всё равно разрешено. Для полной защиты стоит ограничить и явный any через linting и review.

Если тип выводится автоматически, noImplicitAny всё равно ругается?

Нет, если TypeScript смог корректно вывести тип (например, по инициализации), ошибки не будет. Например:

let n = 123; // Тип number, не any

Включение strict автоматически включает noImplicitAny?

Да, флаг strict включает множество строгих проверок, в том числе и noImplicitAny. Но его можно отключить вручную, если требуется.

Типовые ошибки и анти-паттерны

Оставлять явный any во многих местах — теряется смысл строгой типизации.
В большом коде не запускать проект с noImplicitAny, полагаясь на "авось" — множество скрытых ошибок.
Добавлять типы "как-нибудь, лишь бы скомпилировалось", не задумываясь о корректности.

Пример из жизни

Негативный кейс

В проекте отключен noImplicitAny, большинство API-обработчиков принимает параметры без явного типа. При внедрении новых бизнес-логик разработчики ошибаются в именах свойств, но ошибки всплывают только на проде.

Плюсы:

Простой и быстрый старт кода.
Легче мигрировать с JS.

Минусы:

В продакшене появляются ошибки, которые можно было бы найти статически.
Рефакторинг и масштабирование усложняются.

Позитивный кейс

После включения noImplicitAny весь код был постепенно отрефакторен, неявные any устранены. Начали использовать редактор с подсветкой типов и автодополнением. Вновь появляющиеся ошибки сразу фиксируются на этапе сборки.