Проекты
Эта страница должна работать как кураторский слой поверх GitHub, где у каждого репозитория появляется контекст, который трудно уместить в обычный README.
Опубликованные npm-пакеты
@omnicajs/vue-remote
Это самый явный публичный пример работы вокруг сторонних UI-расширений, границ изоляции и scaffolding для недоверенного или отдельно разрабатываемого интерфейсного кода. Этот пакет хорошо показывает архитектурную сторону профиля, потому что речь идет не просто об очередной UI-утилите, а о целой модели интеграции.
Что здесь особенно важно:
- remote rendering и границы изоляции как продуктовая задача
- scaffolding для разработки расширений, а не единичный эксперимент
- документация и tooling как часть истории самого пакета
@modulify/validator
Этот пакет рассматривает валидацию как переиспользуемую прикладную задачу, а не как узкий form-helper. Он построен вокруг правил, композиции и ясности API.
Что здесь особенно важно:
- переиспользуемые validation rules и проверки данных на уровне приложения
- library design с акцентом на поддерживаемость и расширяемость
- практическая польза без сильной привязки к одному фреймворку
@modulify/morph
Этот проект хорошо подходит для разговора о преобразовании и reshaping структур данных. Это компактный и понятный пример utility-дизайна с четкой границей абстракции.
Что здесь особенно важно:
- transformation pipelines и преобразование структур
- composable utility design
- стремление к обобщенным абстракциям, которые можно переносить между проектами
@cmath10/jmask
Это самый явно UI-ориентированный пакет в наборе. Он посвящен практичной frontend-инженерии вокруг пользовательского ввода, браузерного поведения и переиспользуемых паттернов работы с формами.
Что здесь особенно важно:
- browser-facing инженерия с понятной продуктовой ценностью
- внимание к UX-деталям в поведении input-элементов
- упаковка практичного frontend-поведения в переиспользуемую единицу
@modulify/pkg
Этот пакет посвящен package-oriented tooling и локальным workflow. Он продолжает библиотечную линию в сторону package maintenance и development ergonomics, а не только runtime-кода.
@modulify/git-toolkit
Этот пакет посвящен Git automation и tooling для мейнтейнеров, особенно рядом с release- и conventional-commit-направлением.
modulify/conventional
Эта монорепа — набор release-system инструментов вокруг Conventional Commits. Она объединяет несколько более мелких пакетов для анализа git-истории, рекомендации версии, генерации changelog и оркестрации релиза.
Опубликованные пакеты в этой монорепе:
@modulify/conventional-git
Тонкая обертка над git с разбором conventional commits и вспомогательными утилитами для semantic tags.
@modulify/conventional-bump
Пакет для рекомендации следующей semantic version на основе истории git.
@modulify/conventional-changelog
Пакет для генерации changelog по git-истории и настраиваемым шаблонам.
@modulify/conventional-release
Более высокоуровневый пакет оркестрации релиза, который связывает versioning, обновление changelog и release-коммиты в единый поток.
Публичная ecosystem-work, которая еще не оформлена как основной пакетный акцент
modulify/m3-web
Это supporting piece для UI-system work внутри более широкой экосистемы modulify. Он добавляет к utility- и tooling-пакетам отдельный UI-слой.
Контекст организаций
modulify
modulify — это мой собственный зонтичный проект. Я развиваю его в основном сам, иногда с небольшой помощью коллег в нерабочее время, если им интересно поучаствовать в каком-то из направлений. Под этим именем я собираю библиотеки самого разного назначения: general-purpose пакеты, tooling, UI-системы вроде m3-web, а со временем и backend-направления. Текущий JavaScript- и TypeScript-слой для меня только первая оформленная часть этой более широкой идеи. Логотип для него нарисовала моя сестра — 2D-художница, работающая под именем JackHook.
omnicajs
omnicajs связан с моим текущим местом работы, но не завязан на один конкретный CRM-продукт. Это место, куда мы выносим библиотеки и tooling для разработки web-интерфейсов, когда они действительно кросспродуктовые и должны оставаться пригодными не только внутри одного приложения. Поэтому именно там логично держать переиспользуемую extension infrastructure, примитивы UI-композиции и инструменты разработки, которые хочется применять где угодно, где они окажутся полезны.