Привет, Хабр! Меня зовут Виктор, я являюсь Web разработчиком в MOEX. Программирую на TypeScript/Java и это моя первая статья, в которой я хочу поделиться историей создания fsd-forge
— CLI-инструмента для упрощения работы с архитектурой Feature-Sliced Design (FSD) в проектах на React и TypeScript. В этой статье я расскажу, почему решил создать этот инструмент, как он устроен, какие проблемы решает, и какие уроки я вынес из процесса разработки.
Что такое Feature-Sliced Design и зачем нужен CLI?
Feature-Sliced Design — это архитектурный подход для структурирования фронтенд-приложений, который помогает организовать код в масштабируемых проектах. FSD делит приложение на слои (app
, pages
, features
, widgets
, entities
, shared
), делая код модульным, читаемым и легким для поддержки. Однако создание новой структуры FSD или добавление сущностей (например, страниц или виджетов) вручную занимает время и чревато ошибками, особенно в больших командах.
Идея fsd-forge
родилась из личной потребности. Работая над несколькими React-проектами, параллельно переписывая с Angular на React еще один, я заметил, что:
Создание FSD-структуры вручную утомительно: нужно создавать папки, файлы компонентов, тестов, стилей и экспортов;
Команды часто допускают ошибки в именовании (например, не используют PascalCase);
Разные проекты используют разные препроцессоры стилей (LESS, SASS, SCSS), и их настройка отнимает время.
Я подумал: почему бы не автоматизировать этот процесс? Так появился fsd-forge
— CLI, который инициализирует FSD-структуру и генерирует сущности с учётом выбранного препроцессора стилей, строгой валидацией и поддержкой TypeScript.
Зачем всё это?
Основные причины:
Экономия времени: Автоматизация создания папок, компонентов, тестов и API-заглушек сокращает рутинную работу (я попросту устал копировать файлы и создавать их вручную).
Стабильность и консистентность: Строгая валидация PascalCase и единый формат файлов обеспечивают одинаковую структуру в команде.
Гибкость со стилями: Поддержка LESS, SASS и SCSS позволяет адаптировать CLI под разные проекты.
Кроме того, я хотел создать инструмент, который будет простым в использовании, но достаточно мощным для реальных проектов. И, честно говоря, мне просто понравилось писать CLI :)
Как устроен fsd-forge?
Архитектура CLI
fsd-forge
— это npm-пакет, написанный на TypeScript с использованием модульной архитектуры. Я вдохновлялся принципами FSD, разделив код на логические слои:
│ ├── config/ # Конфигурации (.fsdrc, tsconfig.json)
│ ├── templates/ # Шаблоны для файлов (сущности, корневые файлы)
│ ├── commands/ # Команды CLI (init, add, forge)
│ ├── utils/ # Утилиты (валидация, работа с файлами)
│ ├── types/ # Типы (EntityType, Preprocessor)
│ ├── cli.ts # Точка входа
config/: Содержит логику работы с
.fsdrc
(хранение выбранного препроцессора) и шаблонtsconfig.json
.templates/: Шаблоны для сущностей (
widget
,feature
,page
) и корневых файлов (index.tsx
,App.tsx
,styleModules.d.ts
).commands/: Реализация команд
init
(инициализация),add
(генерация сущностей),forge
(интерактивный режим).utils/: Утилиты для валидации имён (PascalCase) и работы с файлами/папками.
types/: Определения типов
EntityType
(widget
,feature
,page
) иPreprocessor
(less
,sass
,scss
).
Что дальше?
fsd-forge
уже решает основную задачу — автоматизацию создания FSD-структуры. Но есть планы по улучшению:
Добавить проверку, чтобы не перезаписывать существующие файлы.
Генерация
hooks.ts
илиmodel.ts
для сущностей.Добавление команды
forge lint
для проверки структуры проекта на соответствие FSD.
Заключение
fsd-forge
— это open-source проект, и я буду рад вашим идеям и улучшениям! Исходный код доступен на GitHub. Если хотите внести свой вклад, форкните репозиторий, создайте PR или напишите мне о ваших мыслях! Надеюсь она сэкономит вам время и сделает работу с FSD проще. Можете критиковать в комментариях, я открыт к этому!
GitHub: тык
Комментарии (2)
dominus_augustus
06.08.2025 14:18Почему вы называете методологию раскладывания файлов по папочкам архитектурой?
Vitaly_js
По моему, если вдохновляться fsd, то какие вещи можно без изменения от туда брать. FSD он не только про размер строительных блоков, но и отношения между ними.
Вот вы пишете: Архитектура CLI. Дальшее идет перечисление ваших слоев и объяснением их семантики. И тут сразу несколько вопросов. Почему вы решили отказаться прям от всех слоев fsd? Каким образом выстроены отношения между слоями? Из представленного описания не очевидно направление зависимостей между слоями. Какие еще строительные блоки есть в вашей архитектуре?
Просто для примера рассмотрим, в fds есть слой app. У вас есть файл-простыня cli.ts. В нем куча захардкоженных сообщений, настроек и что-то мне подсказывает, что если вы заходите это расхардкодить то работать с этим сможет одновременно только один человек. Модульность как раз таких вещей позволяет избежать.