22 апреля 2019 года был выпущен Facebook response-scripts v3.0.0. В этой статье я попытаюсь описать процесс миграции в целом, с некоторыми проблемами и решениями для них, с которыми я столкнулся во время этого переноса.

Наиболее заметные особенности этого выпуска:

  • React Hooks теперь полностью поддерживаются
  • Линтинг TypeScript теперь интегрирован в ESLint
  • Абсолютный импорт с использованием jsconfig.json или tsconfig.json
  • Кроме того, теперь исправлена ​​ошибка, из-за которой response-scripts test - охват невозможно было запустить в режиме watch.

Обновить скрипты реакции

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

or

Примечание. во время обновления вы можете увидеть, что пакет response-scripts зависит от другой версии некоторых ваших зависимостей (например, eslint или любую другую зависимость). В этом случае вы можете удалить явно указанные зависимости, с которыми он конфликтует, из файла package.json (все, кроме typescript ), а затем - повторно запустите команду установки выше. В случае машинописного текста вам нужно будет ввести и сохранить его версию внутри package.json. Таким образом, вы шаг за шагом доверяете сценариям реакции установку и поддержку зависимостей, от которых он зависит (и очистите ваш package.json файл в качестве небольшого бонуса).

Перенести правила из TSLint в ESLint

Следующим важным шагом может быть перемещение всех ваших правил линтинга Typescript из tslint.json в .eslintrc:

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

  • если у вас уже есть существующая конфигурация .eslintrc, убедитесь, что она уже расширяет «response-app». Это сделано для того, чтобы правильно показать вам все связанные правила response-script во время ручного линтинга или внутри вашего выбранного редактора кода (в моем случае это VSCode).
  • теперь скопируйте и вставьте все свои правила tslint из раздела tslint.json - ›« rules » в .eslintrc - раздел ›« правила ».
  • следующим шагом будет запуск eslint с приведенной ниже командой и проверка возможных синтаксических ошибок правил:

Примечание. Ошибки будут связаны с установленными для правил true или false, которые ожидают 0, 1, 2 или «выкл.», «предупреждать» , «ошибка» в качестве значения соответственно.

  • Если у вас есть несколько конфигураций tslint для линтинга кода на разных этапах (например, отдельный dev и отдельный pre-commit config), не забудьте проделать с ними ту же операцию, но присвоить файлам соответствующие имена.

Примечание. в качестве альтернативы вы можете пропустить все, что связано с копированием правил выше, и просто переписать свои правила с нуля, используя документацию http://ESlint.org/docs/rules, а затем продолжить со следующего шага.

  • исправьте свои сценарии npm внутри package.json, чтобы использовать eslint вместо tslint .

Примечание. при необходимости вы можете указать необходимую конфигурацию для каждого отдельного сценария npm с помощью флага - config (например, eslint - config .eslintrc - исправить \ ”src / ** / *. {Ts, tsx, js} \).

  • теперь линте ваши файлы и исправьте все возможные ошибки
  • удалите все tslint связанные файлы и конфигурации из package.json и повторно запустите свой npm install или yarn, чтобы очистить папку node_modules от устаревших зависимостей.

Абсолютный импорт

Теперь сценарии реакции поддерживает абсолютный импорт на основе jsconfig.json / tsconfig. json baseUrl. Чтобы настроить его, создайте или обновите свой jsconfig.json или tsconfig.json со следующими строками:

Примечание. в настоящее время единственными поддерживаемыми параметрами для baseUrl являются node_modules, которые устанавливаются по умолчанию и src.

Начиная с этого момента, вы можете импортировать свои компоненты, указав относительный путь к вашей папке src, вместо того, чтобы писать длинную цепочку наших любимых .. /../../:

Небольшая заметка об именовании файлов Jest-тестов

Если имена файлов ваших тестов не имеют суффикса .spec или .test и, например, называются просто как test.tsx (как это было в моем случае) - они не будут обнаружены с помощью теста сценариев реакции бегун. В результате вам нужно будет переименовать их не так, чтобы они назывались test.tsx, а чтобы включить этот суффикс в их имя (например, Button.test.tsx).

Еще одно замечание о тестировании сценариев реакции

Если в процессе разработки вы полагались на тест сценариев реакции - покрытие, запускаемый только один раз (например, запуск CI или какой-либо перехватчик перед фиксацией), теперь он выполняется. в режиме смотреть по умолчанию. Чтобы исправить это, вам нужно добавить флаг - watchAll = false, чтобы убедиться, что он не будет работать в режиме просмотра.

Удачи!