Что это простыми словами
class-validator — это контролёр на входе, который проверяет данные перед тем, как они попадут в приложение.
Аналогия: представьте вход в кинотеатр. Контролёр проверяет билеты: правильная ли дата, тот ли зал, не поддельный ли билет. Неправильный билет — человека не пропускают. class-validator делает то же самое с данными: пользователь ввёл email — библиотека проверяет, правда ли это похоже на email, а не просто набор букв. Ввёл возраст — проверяет, что это число и оно разумное, а не минус сто.
Если данные неправильные, приложение их не примет и вернёт понятную ошибку. Так защищаются от мусора и ошибок.
Официальное определение
Теперь, когда суть понятна, вот как это описывают в вакансиях и документации. Эту формулировку вы будете встречать у заказчика, в резюме и в речи разработчиков — теперь вы понимаете, что за ней стоит.
«class-validator — декларативная библиотека валидации на основе декораторов для TypeScript и JavaScript».
Разберём по словам. «Валидация» — это проверка данных на правильность. «Декларативная» значит, что правила проверки записываются явно и наглядно, а не спрятаны внутри кода. «Декораторы» — это специальные метки в коде вроде @IsEmail или @IsNumber, которые показывают, какое правило применить к каждому полю. Выглядит как стикер на коробке: «хрупкое», «скоропортящееся» — сразу понятно, что с ним делать.
Какую задачу решает
Когда пользователь отправляет данные на сервер — заполняет форму, делает запрос из приложения — эти данные могут быть неправильными: случайно или специально. Кто-то опечатался в email, кто-то ввёл текст вместо числа, кто-то пытается намеренно сломать приложение, подсунув странные символы.
Без проверки эти данные попадут внутрь системы и могут вызвать ошибку или даже сломать что-то. class-validator ловит неправильные данные на входе, сразу сообщает пользователю, что не так, и не даёт мусору пройти дальше.
Побочная польза: правила проверки записаны прямо рядом с описанием данных, поэтому другому разработчику сразу видно, что ожидается. Это как подпись на банке: «срок годности до...» — не нужно гадать.
К какой экосистеме относится
Язык — Node.js (JavaScript и TypeScript).
Фреймворк — чаще всего NestJS. Формально class-validator можно использовать где угодно в Node.js, но на практике вы встретите его почти всегда именно в связке с NestJS.
Специальность — backend-разработчик.
Часто рядом с class-validator встречается class-transformer. Это не одно и то же, но они работают вместе: class-transformer превращает сырые данные в удобный формат, а class-validator проверяет их на правильность. Часто их указывают парой в вакансиях.
Чем заменяется
class-validator — не единственная библиотека для проверки данных. Ту же задачу решают Joi, Yup и Zod. В одном проекте обычно используют что-то одно.
Главное: переход между ними дешёвый. Разработчик, который работал с class-validator, разберётся в Joi или Zod за считаные дни — идея у них одна, отличается только способ записи правил. Это не разные профессии и даже не разные школы, а скорее разные модели инструмента, делающего одну работу.
Что не путать
class-validator ≠ class-transformer. Первая проверяет данные на правильность, вторая преобразует их из одного формата в другой. Они работают вместе, но это разные инструменты.
class-validator ≠ TypeORM. TypeORM работает с базами данных, class-validator — с входящими данными ещё до того, как они попадут в базу. Обе библиотеки часто встречаются в NestJS-проектах, но делают разное.
Валидация на сервере ≠ валидация в браузере. class-validator работает на сервере, на Node.js. Проверка данных в форме на странице в браузере — это другая история, там другие библиотеки.
Насколько это важно при отборе
Короткий ответ: обычно это НЕ повод отбраковывать кандидата.
Самая частая ошибка новичка-рекрутера — искать строго «NestJS + class-validator» и отсеивать сильного разработчика, у которого в резюме указан Joi или Zod. Он освоит class-validator за несколько дней, потому что задача та же. Отсеивая по конкретной библиотеке валидации, вы теряете хороших людей и затягиваете поиск.
Правильный подход: смотрите, есть ли у кандидата опыт с любой библиотекой валидации данных. Если есть — этого достаточно. Если в вакансии жёстко написано «только class-validator», уточните у нанимающего менеджера, действительно ли это принципиально: часто оказывается, что нет.
Когда всё же стоит обратить внимание: если кандидат вообще нигде не упомянул валидацию или проверку данных, а вакансия предполагает работу с пользовательским вводом или API — это повод спросить, как он обеспечивал корректность данных в проектах.
Это общий ориентир. В разных компаниях требования отличаются, поэтому всегда сверяйтесь с текстом конкретной вакансии.