Миграция на строгий TypeScript: наш путь и собственное решение

[maxcat]

Строгий TS это C# 😄

[gev]

А строгий C# – это F# 😄

[difuks]

Спасибо за упоминание в статье и интересный материал!

Пара вопросов:

1. В случае с IDE, как вы решаете кейс, когда в одной папке располагаются сразу много файлов и вы хотите включить стрикт только для части из них? Из очевидного приходит в голову — переместить часть файлов в другую папку. Но это повлечет к изменениям в структуре проекта, что не всегда может быть приятно

2. Не совсем понял часть про "Взаимодействие с сервером TypeScript". В каких кейсах это используется?

[movl]

У нас сейчас стрикт включен для всех файлов проекта по умолчанию. А для сборки используется отдельный tsconfig без строгого режима. Проверка в CI/CD происходит только для тех файлов, которые изменились в рамках задачи. То есть, в нашем случае, не возникает проблемы, когда необходимо как-то точечно разделить проверку по файлам. Но понимаю, что могут быть кейсы например с тестами или чем-то похожим, в этом случае можно воспользоваться примерно следующей конфигурацией, хотя не уверен что это лучший путь:

Заголовок спойлера

tsconfig.json

{
  "files": [],
  "references": [
    { "path": "./tsconfig.strict.json" },
    { "path": "./tsconfig.not-strict.json" }
  ]
}

tsconfig.strict.json

{
  "compilerOptions": { "strict": true },
  "include": ["./src/strict.ts"],
  "exclude": ["./src/not-strict.ts"]
}

tsconfig.not-strict.ts

{
  "compilerOptions": { "strict": false },
  "include": ["./src/not-strict.ts"],
  "exclude": ["./src/strict.ts"]
}

Сейчас еще решил проверить как это будет работать в связке с вашим плагином. В общем всё хорошо, как и ожидалось: то есть плагин можно настроить только на подсветку, а для автоматизации проверки в CI использовать утилиту.

Заголовок спойлера

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

[difuks]

Спасибо за ответ!

Проверка в CI/CD происходит только для тех файлов, которые изменились в рамках задачи

А если в таком случае изменится файл A, который в свою очередь импортируется в файле B (который не был изменен), получится ли отследить, что файл A мог поломать B?

[movl]

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

Задача в пайплайне с проверкой строгих типов, нужна примерно с такой целью: например разработчик поменял одну строчку где-то в старом файле. При этом сам файл весь светится красным, но разработчик точно знает, что его изменения не повлияют на успех сборки. И раньше такие изменения пропускались через пайплайн, а сейчас их заворачивает утилита. То есть если залез куда-то в старый код что-то исправить, то придется и причесать типы заодно.

[movl]

В теории можно попробовать при помощи того же сервера выдернуть все зависимости проверяемого файла, и рекурсивно их добавить в список для проверки. Возможно это даже будет работать эффективнее чем прогонять через tsc --noEmit. Правда на такую проверку будет влиять общая связность кода, впрочем это решается параметром максимальной глубины. В любом случае не уверен, что выдача проблемных зависимостей, будет полезна в рамках того процесса миграции, что мы у себя наметили. Но в качестве какого-то вспомогательного инструмента, наверное имеет смысл рассмотреть реализацию этой логики. Спасибо за вопрос!