Задний план

Популярность Typescript растет, и легко понять, почему. Статическая типизация помогает общаться через код и может помочь вашей команде выявлять ошибки до того, как они попадут в рабочую среду. Хотя желание обновить веб-приложение до этого нового языка может быть убедительным, дальнейший путь не ясен на 100%. Страшно преобразовать всю вашу кодовую базу без негативного влияния на выпуски функций.

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

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

По мере роста вашей команды ручная проверка больше не масштабируется, поэтому этот шаг следует автоматизировать.

Представляем..

https://github.com/erictsai6/typescript-migration-linter

Это bash-скрипт, предназначенный для выполнения в целевой ветке путем сравнения ее с базовой веткой. В большинстве случаев это origin/master.

Использование ./main.sh <BASE_BRANCH> <APP_DIRECTORY> <BLACKLIST_DIRECTORY>

  • BASE_BRANCH — это базовая ветвь, в которую вы планируете влиться. Для многих команд это будет origin/master.
  • APP_DIRECTORY — это относительный путь к тому месту, где находится JS-код вашего приложения. Дополнительные каталоги могут быть разделены запятой.
  • BLACKLIST_DIRECTORY — (необязательно) это относительный путь к каталогам, которые вы хотите игнорировать для применения правил JS. Дополнительные каталоги могут быть разделены запятой.

Оба параметра каталога будут принимать регулярное выражение, если это необходимо.

Как это работает

Сценарий использует Git CLI для обнаружения различий между текущей ветвью и целевой ветвью. Обратите внимание, что если ваш процесс CI/CD предполагает слияние с целевой веткой перед проверкой, то эта стратегия не сработает. (Хотя можно спросить, почему вы потенциально рискуете повредить свою целевую ветку)

Затем сценарий bash проверит наличие любых добавленных, измененных и переименованных файлов, сравнивая текущую ветку с целевой веткой. Если какой-либо из файлов является частью APP_DIRECTORY, а не частью необязательного BLACKLIST_DIRECTORY, тогда он будет отслеживать его в массиве и выводить на стандартный вывод, заставляя процесс завершиться со статусом 1.

Частный случай — измененные файлы

Когда мы впервые представили сценарий, наши разработчики быстро утонули в обновлениях миграции. Предположим, цепочка зависимостей ниже

Если разработчик обновляет file_a.js и преобразует его в file_a.ts, ему, возможно, придется обновить оператор импорта в file_b.js. (Необходимость изменения оператора импорта зависит от настройки вашего приложения). Это затем ставит их на крючок для преобразования file_b.js, потому что они теперь изменили его, что затем ставит их на крючок для обновления file_c.js. Можно видеть, что это может выйти из-под контроля в приложении любого размера, поэтому мы внесли коррективы, чтобы попытаться определить, когда изменение было значительным.

Если мы посмотрим на фрагмент bash ниже, вы увидите специальное место, где мы пытаемся решить эту проблему.

Используя --numstat, мы можем получить более подробную информацию о количестве строк, добавленных или удаленных в каждом файле. Затем мы можем отфильтровать только существенные изменения файлов. Мы обнаружили, что 5 добавленных строк — это хороший порог, но мы могли бы сделать его более разумным, приняв во внимание значение lines_removed.

Плавник

Как всегда, не стесняйтесь настраивать сценарий под свои нужды. Удачного кодирования.