С монорепой-то понятно)

Вот! Теперь тебе нужно объединить все репы в одну )

Йоу

Поделитесь опытом, как кошерно шарить gql-схему между репозиторием, где эта схема описана, и репозиториями-клиентами. Моя хотелка — генерить typescript-декларации из схемы.


Вижу два варианта

— настроить сетап, который смотрит на сервер со схемой и по событию генерит декларации. Предвижу проблемы с доступностью и актуальностью этого сервера (надо накатить туда «тот самый» коммит, надо авторизовываться, иногда впн-туннель поднимать)

— настроить ci вокруг репозитория со схемой, чтобы схема деплоилась в стандартный реджистри в виде артефакта с версионированием, нотификациями об изменениях и прочими свистелками. Предвижу проблемы с гемором настройки


Как у вас? Какие есть подводные камни?

Если не монорепо, то еще вариация это отдельный пакет с декларациями, которые генерятся на триггер (или коммит). Клиенты там уже потребляют как хотят, блокируя или не блокируя свои сборки при несовместимых изменениях в схеме. В целом я не понял до конца где важно тебе автоматизировать, в генерации или совсем весь билд процесс, с проверками в потребителях схемы

Проще конечно первый вариант, плюс доступность и актуальность сервера и в том и в другом случае придется решать (а чего это вообще он недоступен?), я бы сделал сначала первый вариант на ручной генерации, автоматизировав позже по необходимости.

Приветствую.
Подскажите пожалуйста, как я могу парсить qraphql схему, что бы динамически получать из нее данные и использовать на фронте?
К примеру я хочу получить массив возможных опций для селекта. Опции это все доступные типы для какой-то сущности.
Это нужно для того, чтобы при добавлении новых опций в схеме, они сразу появлялись на фронте.
Заранее спасибо.

Мне нужно не для линтера, а для динамического кода. Что бы не хардкодить массив опций, а брать из схемы, произвольной длинны