Vest изначально проектировалась как декларативная библиотека валидации, вдохновлённая подходами тестовых фреймворков. Её ключевая идея — описывать правила проверки данных в виде «сессий», где каждая проверка группируется, кешируется и может выполняться условно. На ранних этапах развития библиотека активно меняла внутреннюю архитектуру, что привело к нескольким крупным несовместимым изменениям между версиями.
Основной разрыв между ранними версиями и первым стабильным релизом связан с переходом от экспериментального API к формально закреплённой модели сессий.
Ранние версии допускали более «свободную» структуру описания правил, где порядок вызова функций мог влиять на результат непредсказуемо. В версии 1.0 введена строгая сессионная модель:
create()Ключевое изменение: переход к детерминированной системе выполнения правил.
В ранних версиях структура результата содержала избыточные поля, ориентированные на отладку. В 1.0:
Версия 2.0 стала важным этапом, так как изменила способ организации правил внутри сессии.
До 2.x правила часто писались линейно. После обновления появилась концепция групп:
Breaking change: старые валидаторы без групп могли требовать переписывания структуры.
Одним из ключевых переломных моментов стало уточнение работы асинхронных правил:
Это повлияло на проекты, где использовались запросы к API внутри валидации: поведение стало более предсказуемым, но потребовало адаптации к новому потоку выполнения.
Внутренние вспомогательные функции для условий (например, условные проверки) были переработаны:
В 3.x основной фокус был направлен на ускорение и предсказуемость выполнения.
Старая модель кеширования результатов могла приводить к повторному выполнению одних и тех же проверок. В 3.x:
Breaking change: в некоторых сценариях проверки перестали выполняться повторно при изменении внешних зависимостей без явного сброса состояния.
Ранее зависимости между полями (например, password/confirm password) отслеживались неявно. В 3.x:
Это сделало систему более контролируемой, но потребовало явного указания связей там, где раньше они определялись автоматически.
Структура ошибок была стандартизирована:
В 4.x изменения затронули архитектуру экспорта и интеграции.
Ранее библиотека предоставляла более монолитный API. В 4.x:
Breaking change: проекты, использующие старые импорты, потребовали массового рефакторинга импортных путей.
Хотя библиотека работала с типами и раньше, в 4.x:
Это привело к тому, что ранее «гибкие» конструкции стали более строго типизированными и иногда требовали явного указания типов там, где раньше они выводились автоматически.
Условные блоки валидации получили новую модель исполнения:
Across major versions, наиболее критичные разрывы касались трёх направлений:
Типичный эффект миграции между версиями выражался не только в изменении синтаксиса, но и в изменении логики выполнения валидаторов, что особенно критично для форм с комплексной бизнес-логикой.
На протяжении всех крупных версий наблюдалась тенденция к:
Ранние версии допускали более «размытые» сообщения, тогда как поздние версии требуют строгой привязки каждой ошибки к конкретному правилу валидации.
Хотя формально это не всегда фиксировалось как breaking change, фактически произошёл сдвиг:
Это проявилось в каждом крупном релизе через ужесточение правил выполнения, уменьшение неявного поведения и переход к более явным контрактам API.