Frontend

Настройка инструментов

Проект мультиплатформенный (должен работать на Windows, Linux и MacOS без костылей вроде Ubuntu for Windows).

Использовать WebStorm или Visual Studio Code. Нужно отключить safe write в IDE.

Настройка Webstorm

• Плагины:
  • IDE Settings Sync - синхронизация настроек, специфичных для пользователя;
  • Styled Components;
  • JS GraphQL;
  • .ignore - поддержка .gitignore;
  • Markdown Navigator;
  • Jenkins Control Plugin - работа с Jenkins из IDE;
  • PlantUML integration;
• Managing Tasks and Contexts:
  • Переключение между задачами с сохранением контекста и созданием веток
  • Изменение статуса задач
  • Учет и загрузка времени

В браузере должны быть установлены react-devtools, redux-devtools-extension, apollo-client-devtools.

Почему именно эти IDE

NB: Проект еще не настроен для VS Code

• Они больше всего используются в компании, и проект уже настроен для них (так, в WebStorm уже будут включены линтеры и FileWatcher для prettier, а также настроена валидация сообщения коммита).

Процесс написания кода

Используется Hot Module Replacement (HMR), что позволяет писать код и сразу же видеть результат (без перезагрузки страницы). Это работает для компонентов приложения и для reducer'ов. Для остального кода страница автоматически обновится. HMR не работает для кода в конструкторе и декорированных функций (в частности, autobind). В таких случаях надо обновлять страницу вручную.

Используются source maps.

Код фронтенда пишется исключительно на typescript.

Сообщение коммита

Как писать сообщение коммита.

Номер задачи автоматически подставляется в сообщение (subject) коммита, поэтому работать надо в ветке задачи (AB-123).

Сообщение коммита валидируется с помощью хуков гита. Оно должно быть вида AB-123: Add feature (префикс задачи с пробелом ставится автоматически). Длина строк, отделение subject от body и отсутствие точки в subject также валидируются.

Контроль качества кода

Перед коммитом:

• staged-файлы проверяются необходимыми линтерами (tslint, stylelint, eslint);
• staged-файлы обрабатываются prettier;
• все файлы проверяются tsc (типы, неиспользуемые переменные);
• проверяется соответствие yarn.lock и package.json.

Это происходит автоматически с помощью хуков гита (lint-staged). В критических ситуациях хуки можно отключить с помощью --no-verify (использовать с осторожностью).

Почему именно так

• Практика показала, что вывод консоли часто игнорируется, и в итоге ошибки нарастают, как снежный ком.
• Линтеры и prettier выполняются только для staged-файлов.
• Предотвращаются бессмысленные коммиты AB-123: Fix linter errors.
• Ошибки можно исправлять, находясь в контексте изменений, которые их вызвали.
• Соответствие yarn.lock и package.json гарантирует, что все зависимости добавляются через yarn.