Как организовать единый стиль кода для компонентов
Что проверяют
Понимаете ли вы, что единый стиль держится на автоматике, а не на договорённостях в чате. Интервьюер хочет услышать, что вы отдадите инструментам, а что закрепите соглашениями и ревью. Следом часто спрашивают, как внедрить это в проект, где уже тысяча файлов в разном стиле.
Как отвечать
Разложите ответ по уровням:
- форматирование: Prettier с общим конфигом в репозитории, чтобы о пробелах и кавычках больше не спорили. Конфликтующие правила ESLint выключает
eslint-config-prettier. Альтернатива «всё в одном» это Biome; - правила кода: ESLint с плоским конфигом
eslint.config.js, наборы для TypeScript,eslint-plugin-react-hooks,jsx-a11y, порядок импортов. Плюс TypeScript в режимеstrict; - стили: один подход на проект, CSS Modules, Tailwind или BEM, и Stylelint под него. Цвета, отступы и шрифты живут в дизайн-токенах на CSS-переменных, а не числами в компонентах;
- структура компонента: папка с компонентом, стилями, тестом и story рядом,
PascalCaseв именах, единые названия пропсов (variant,size,onChange), шаблон нового компонента через plop или скрипт; - витрина: Storybook показывает все компоненты и их состояния, новый разработчик смотрит туда, а не пишет свою кнопку;
- принуждение:
lint-stagedс Husky проверяет изменённые файлы перед коммитом, CI блокирует слияние при ошибках. Хук на машине разработчика можно обойти, CI нельзя.
Для старого проекта: форматирование одним отдельным коммитом, который вносят в .git-blame-ignore-revs, правила ESLint включать постепенно, начиная с предупреждений, а новые файлы сразу держать в строгом режиме.
Где спотыкаются
Пишут документ со стайлгайдом и считают задачу решённой. Без линтера в CI он перестаёт соблюдаться за пару месяцев.
Смешивают подходы к стилям: часть компонентов на CSS Modules, часть на styled-components, часть с инлайном. Единый стиль тут невозможен в принципе.
Заставляют ESLint форматировать параллельно с Prettier. Инструменты правят один и тот же код по-разному и спорят на каждом сохранении.