SSPS - Единый стандарт для структуры проекта

Стандарт SSPS определяет требования к структуре и наименованию файлов и папок в проекте.

Везде kebab-case

Использование нижнего регистра и дефиса является обязательным для всех папок и файлов проекта. Это осознанный выбор регистра, который обеспечивает согласованность и гарантирует отсутствие проблем. Такой подход предотвращает конфликты в разных операционных системах и системах контроля версий (Git), где чувствительность к регистру может отличаться, вызывая ошибки при слиянии веток или сборке на CI.

Использование kebab-case решает следующие проблемы:

• Исключает хаос вида getPrice.ts, Price.tsx и Name.test.ts в одной директории.
• Сложные названия вроде CuteIDKOKReader преобразуются в читаемый cute-id-kok-reader.ts.
• Защищает от багов Case Sensitive FS.

Почему не snake_case:

• Требует избыточного использования клавиши Shift.
• Плохо читается в вебе (например, если файл отображается как ссылка с подчеркиванием, _ сливается с линией).
• Google официально не рекомендует использовать нижнее подчеркивание.

Пути в импортах выглядят единообразно и легко читаются. Единственное допустимое отступление это системные файлы в корне репозитория, такие как README или CONTRIBUTING, поскольку их верхний регистр продиктован общепринятыми стандартами документации.

Контекст через вложенность

Название файла не должно дублировать информацию, которую уже предоставляет структура папок. В SSPS контекст определяется местоположением, то-есть если файл находится в features/auth, то именование auth-login-form.tsx избыточно. Правильно, login-form.tsx.

Переход от названий вроде HeaderUserMenuAvatar к структуре widgets/header/ui/user-menu/avatar позволяет сохранять имена файлов краткими и точными.

Архитектурные принципы FSD

Проект выстраивается по слоям с четкой зоной ответственности. Глобальные группы (entities, features, widgets) всегда именуются во множественном числе. Конкретные модули (слайсы) внутри них, в единственном. Внутренние сегменты (ui, model, api) остаются стандартными.

Это создает предсказуемую архитектуру, задача по изменению корзины всегда приведет в features/add-to-cart, где интерфейс и логика четко разделены. Использование единого регистра (kebab-case) делает проекты однообразными, что поможет быстрее ориентироваться и решать задачи.