Конфигурация и feature flags

Анализ текущего подхода и план единого модуля конфигурации и флагов фич. Отдельный аспект — переопределение переменных из настроек через окружение — описан в Variables_Env_Override.

Обоснование

В enterprise и Low-Code платформах конфигурация среды (URL, флаги фич, режимы) выносится в единую точку входа с типизацией и валидацией при старте. Это снижает ошибки деплоя (опечатки в env), упрощает смену сред (dev/staging/prod) и поддержку remote config. Риск при отсутствии: разрозненные чтения import.meta.env по коду, невозможность централизованно включить/выключить фичу по среде или по tenant без пересборки.

Текущее состояние

Переменные окружения

• Vite: import.meta.env.VITE_* — сборка (BASE_URL, API URLs, default locale, branding и т.д.).
• Нет типизированного слоя доступа: каждая фича обращается к import.meta.env напрямую; при добавлении переменной легко забыть описать тип в env.d.ts.

Feature flags

• shared/utils/debug/feature-flags.ts: один источник — строка VITE_FEATURE_FLAGS, разбитая по запятым; тип FeatureFlag перечисляет известные флаги (debug-panel, cancel-all-logs); функция isFeatureEnabled(name).
• Плюсы: просто, без сервера. Минусы: только build-time, нет разделения по средам/тенантам без пересборки, нет remote config.

Доменная конфигурация (Settings)

• Endge: RSettings / settings в домене — vars, auth, vocabs, sse, updates, customSections. Это конфигурация приложения с точки зрения домена (Payload), а не инфраструктурные флаги и env.
• Не подменяет потребность в едином месте для «включить панель отладки», «базовый URL API», «включён ли новый редактор» и т.д.

Чего не хватает

1. Единая точка входа для всего, что приложение считает «конфигом»: env, feature flags, при необходимости remote config.
2. Типизация и валидация: один список ключей и типов (string, number, boolean, string[]), описание в одном месте, проверка при старте.
3. Разделение по средам: dev / test / staging / prod без дублирования кода (например, объект config по import.meta.env.MODE или по отдельной переменной).
4. Feature flags:
   • Расширяемый набор флагов без жёсткого enum в одном файле (например, регистрация флагов или конфиг-объект).
   • Опционально: runtime-флаги с сервера (remote config) для включения фич без деплоя.
5. Безопасность: секреты не в env фронта, а только URL и публичные ключи; чувствительные данные — с бэкенда или через защищённый канал.

Рекомендуемое направление

Модуль конфигурации (в core или отдельный пакет)

• Config — один объект/фасад, доступный после инициализации приложения (например, AppCore.config или Endge.config), собранный из:
  • Env: все VITE_* переменные, провалидированные и типизированные (один schema или интерфейс в TypeScript).
  • Feature flags: те же build-time флаги из строки/объекта плюс, при наличии бэкенда, поля из ответа «app config» (например, после логина или отдельный endpoint).
• Инициализация: при bootstrap (до рендера критичного UI) — чтение env, опционально запрос remote config, сборка объекта config; при ошибке валидации — явный fail или fallback.
• API: config.get('key'), config.isFeatureEnabled('name'), config.getEnv() — в зависимости от выбранного стиля. Типизация через один интерфейс/тип.

Feature flags

• Оставить build-time флаги как есть, но получать их через модуль конфигурации, а не напрямую из import.meta.env.
• Расширяемый список: не только enum, а, например, объект с описанием флагов (name, description, default, envKey) или регистрация в модуле конфигурации; в коде везде использовать config.isFeatureEnabled('...').
• При появлении backend’а: endpoint вида GET /api/config или включение флагов в ответ приложения после auth; модуль конфигурации при инициализации мержит их в общий объект с приоритетом (runtime перебивает build-time).

Соотношение с доменными Settings

• Settings (RSettings) — что настраивает пользователь/админ в рамках домена (vars, auth, vocabs, интеграции). Используются runtime’ом и приложением для бизнес-логики.
• Config (модуль конфигурации) — что задаёт среда и платформа: env, feature flags, URLs, режимы отладки. Не подменяет Settings, а дополняет: приложение сначала читает Config, затем при загрузке домена — Settings.
• При желании часть «публичных» vars из Settings может дублироваться в Config для быстрого доступа (например, «текущий бренд»), но источник истины для доменных вещей остаётся Settings.

Практические шаги

1. Ввести модуль конфигурации (в @endge/core или @endge/config): сборка объекта из env, типизированный интерфейс, валидация при инициализации.
2. Перенести чтение VITE_FEATURE_FLAGS и isFeatureEnabled в этот модуль; заменить прямые вызовы isFeatureEnabled из shared на вызов через модуль конфигурации.
3. Добавить в конфиг остальные часто используемые VITE_* переменные (BASE_URL, API URLs, default locale, branding key и т.д.) и обращаться к ним только через модуль.
4. Документировать список env-переменных и feature flags в одном месте (например, в этом roadmap или в отдельном разделе документации).
5. При появлении remote config: добавить шаг в bootstrap (запрос конфига), мерж в общий объект, использование в isFeatureEnabled и в config.get(...).

Риски и ограничения

• Миграция существующего кода на единый фасад конфигурации потребует замены прямых обращений к import.meta.env; делать постепенно, чтобы не ломать сборки. Remote config добавляет зависимость от бэкенда при старте приложения — нужен таймаут и fallback.

Вывод

• Имеет смысл выделить единый модуль конфигурации: env + feature flags + при необходимости remote config.
• Feature flags остаются частью этого модуля; доступ только через него, без прямого чтения import.meta.env в фичах.
• Доменные Settings (Endge) не заменяются — они про настройки приложения в домене; конфиг-модуль — про среду, платформу и флаги фич. Переопределение переменных настроек через env — см. Variables_Env_Override.