E
Да, я уже сделал, спасибо Вам двоим большое
Size: a a a
2020 March 19
S
Постоянно вижу вопросы, как сделать в class-validator то, под что нету декораторов. Написал готовое решение на все случаи жизни. Оплату принимаю звездами https://github.com/svtslv/class-validator-callback
AM
Лучше бы сделал класс-валидатор без декораторов )
S
Лучше бы сделал класс-валидатор без декораторов )
Есть такой, называется joi)
VL
Постоянно вижу вопросы, как сделать в class-validator то, под что нету декораторов. Написал готовое решение на все случаи жизни. Оплату принимаю звездами https://github.com/svtslv/class-validator-callback
❤️
AM
Я бы конечно такое в проект не пропустил 😄
S
Я бы конечно такое в проект не пропустил 😄
Вот зря ты так, там даже 2 теста есть)
AM
Не в этом дело. Тут получается какой-то пласт императивной логики, которую невозможно переиспользовать. Лучше сделать нормальный декларативный декоратор и поставить там, где нужна такая валидация.
AM
да, и маленький совет ещё — если уж релизнулся, то ставь версию 1.0.0, версия 0.0.1 это патч для ничего и при установке такой версии уже никакая крышечка не поможет с автообновлениями
S
да, и маленький совет ещё — если уж релизнулся, то ставь версию 1.0.0, версия 0.0.1 это патч для ничего и при установке такой версии уже никакая крышечка не поможет с автообновлениями
Хм, нужно проверить, разве не будет обновлять к 0.0.2?
AM
то же самое с ^0.1.0 — никогда не обновится на 0.2.0
AM
т.е. первая ненулевая цифра фиксирует мажор
S
действительно не работает, ох, пойду все фиксить, спс.
AB
А вообще лучше semver почитать
AB
Коли уж про версии разговор зашёл, у меня есть непонятки по поводу того, когда нужно менять версию в проекте. Допустим я сделал ветку и пилю некоторую фичу, что-то сделал в проекте, что добавило новый функционал, но не решило задачу ветки, должен ли я повышать версию или нет?
AB
Если обратиться в conventional commits, там говорится, что feat должен повышать версию, но мне кажется это не совсем правильно
AM
разработчик сам решает когда и что он повышает, но стандартное правило — мажор.минор.патч
Мажор — крупные изменения, ломающие обратную совместимость
Минор — расширение функциональности
Патч — мелкие правки
Мажор — крупные изменения, ломающие обратную совместимость
Минор — расширение функциональности
Патч — мелкие правки
AM
semver это сигнал потребителю библиотки как относится к изменению версий. Ломать обратную совместимость в минорах (как какая-нибудь Монга) — это фуфуфу и путь к неприятию сообществом.
AM
Во внутренних проектах могут быть совершенно иные правила