Все мы принимаем плохие архитектурные решения. Это нормально, потому что требования к проекту постоянно меняются. И поэтому нужно уметь эффективно мигрировать с легаси на новые решения.
И идеальной ситуацией будет схема:
1. депрекейт фичи в миноре версии x
2. варнинг в версиях x+1,...,x+N-1
3. выпиливание фичи в версии x+N
В таком случае у пользователя есть возможность подготовиться к выпиливанию библиотеки максимально плавно. Такой схеме релизов следуют react, pnpm, Bazel, jest и многие другие.
Однако, зачастую бывает такое, что нужно заменить одно решение на другое. Причём изначальное решение используется в 100500 местах в проекте. К примеру: замена React.useCallback на useEvent. Мы проводим сейчас как раз такую миграцию. И тут основная проблема в трёх местах: нужно как-то донести новое правило до всех членов команды; нужно как-то на code review замену API; нужно как-то контролировать прогресс выпиливания, чтобы не оказаться в ситуации, что у нас будет 100500 одновременных миграций.
Сложность первой проблемы в том что миграции могут длиться годами, а это значит что в проект могут спокойно приходить новые люди. А значит и их нужно посвещать в таинство колдунства;
Вторая проблема же в том, что программисты тратят слишком много времени и сил на PR. И в итоге вместо реальной работы люди начинаются докапываться до кодстайла.
Мы выработали следующее решение этой задачи:
1. Пишем ESLint правило, которое запрещает использовать старое API;
2. Во все места с ESLint ошибками добавляем ignore комменты, которые отключают ESLint ошибку для конкретных строк
3. Добавляем над ignore комментом TODO коммент.
4. В следующий раз когда программист правит файл, то он может выпилить старое API на новое, заодно проверив функциональность логики
Добавить TODO и ignore комменты можно добавить простой командой:
npx suppress-eslint-errors . --extensions=ts,tsx --parser=tsx --rules=no-restricted-syntax
В итоге мы можем легко контролировать количество TODO комментов в коде. Программист видит какой код устарел, так как TODO комменты выделяются в редакторах другим цветом. Легко находить TODO комменты в коде, чтобы постепенно выпиливать старую логику. А ESLint правило позволяет не давать плодить программисту устаревший код.
Одни плюсы, правда если только ты можешь написать ESLint правило