Разработчику
Инструменты для разработчика онлайн: форматирование кода и SQL, генераторы типов TypeScript и Python-моделей, проверка регулярных выражений и валидаторов. Всё в браузере.
Проверка регулярного выражения
Подсветка совпадений, группы захвата с номерами и именами, номер строки, замена и готовые шаблоны
Проверить email, URL, IP, ИНН
Проверка значений и идентификаторов: контрольные суммы ИНН, СНИЛС, ОГРН и карт, причина отказа по каждой строке
JSON в TypeScript
Типы и интерфейсы TypeScript по JSON: вложенные объекты, массивы, объединения, необязательные поля
JSON в Python-модели
Датаклассы, pydantic v2 и TypedDict по JSON: вложенные классы, Optional, значения по умолчанию и разбор кода обратно
Форматировать SQL-запрос
Отступы, регистр ключевых слов, переносы перед JOIN, разбивка AND и OR, минификация в строку
Форматировать и минифицировать CSS
Форматирование и сжатие CSS: отступы, сортировка свойств, чистка дублей и комментариев, размер до и после
Форматировать JS и TS
Отступы, кавычки, точки с запятой и висячие запятые или минификация: размер и разбор по токенам
Конвертер .env и JSON
.env в JSON и обратно: типы значений, кавычки, комментарии, вложенные ключи и таблица ошибок
Зачем разработчику эти инструменты
В работе разработчика много мест, где нужно не написать логику, а привести в порядок текст: разложить ответ сервиса по полям, набросать по нему типы, прочитать запрос из логов, проверить значения из выгрузки. Это рутина, и она дороже, чем кажется: на неё уходят часы, а ошибка в ней тихая — лишний или пропущенный тип всплывёт позже, в рантайме, и искать его будут уже в другом месте.
- Ответ API нужно типизировать в TypeScript, а расписывать интерфейс на десятки полей руками — полдня работы и опечатки в именах.
- Под чужой JSON нужна pydantic-модель: структура перед глазами есть, а как назвать поля, вложенные объекты и необязательные ключи — приходится придумывать.
- SQL-запрос вытащили из логов одной строкой без переносов: ни прочитать, ни понять, почему база его не принимает.
- Клиент прислал .env.example, а тестам и мокам нужен JSON с теми же ключами и значениями — вручную переносить строки долго и легко потерять одну.
- Регулярное выражение не ловит совпадение, и непонятно почему: то захватывает лишнее, то не находит то, что должен.
- Перед загрузкой списка контактов или контрагентов нужно проверить почты, ссылки, ИНН или СНИЛС — глазами по таблице этого не сделать, а маска пропускает опечатку в контрольной цифре.
- Собранный CSS пришёл одной сжатой строкой: правило нужно найти и поправить, а читать минифицированный файл невозможно.
- Чужой минифицированный JavaScript нужно разобрать хотя бы по структуре: где начинается функция, что вызывается и в каком порядке.
Категория собирает инструменты под эту работу: форматирование кода и запросов, генерация типов и моделей по настоящим данным, проверка значений по контрольным суммам, отладка регулярных выражений, перевод файла переменных окружения в JSON. Правило то же, что и в остальных категориях: инструмент решает одну задачу, а близкие варианты собраны настройками в нём же — диалект SQL, отступы, способ объявления модели, набор проверяемых типов. Результат можно скопировать, а где у операции есть обратная — она там же, отдельным режимом: из JSON получаются типы, из типов обратно пример JSON, из .env — объект и наоборот.
Считают инструменты в браузере: фрагменты кода, ответы API, конфигурации и значения из выгрузок никуда не отправляются, не сохраняются и исчезают при обновлении вкладки. Поэтому сюда можно вставлять то, что не хочется отдавать стороннему сервису, — содержимое внутренних сервисов, ключи тестового окружения, данные клиентов.
Частые вопросы о категории
Заменяет ли генератор кода ручную работу и можно ли ему доверять?
Он снимает механическую часть: разложить структуру ответа по полям, назвать типы, расставить отступы и переносы. Решения остаются за вами — какие поля обязательные, как называются сущности, что делать с расхождением типов, — поэтому вывод генератора это черновик, который читают и правят. Точность зависит от данных: чем больше образцов одного ответа вставите, тем лучше результат. Поле, которое встретилось не во всех образцах, помечается необязательным, а значения разных типов собираются в объединение — такое место видно сразу в коде, а не через неделю в рантайме.
Исходники и данные уходят на сервер?
Нет. Все инструменты категории считают результат в браузере на JavaScript: вставленный текст не отправляется по сети, не сохраняется и не логируется. Проверить это можно так: откройте инструмент, отключите интернет и продолжите работу — разбор и вывод идут точно так же, потому что сервер в них не участвует. Обратная сторона в том, что история не ведётся: при обновлении вкладки введённое пропадёт, поэтому результат лучше скопировать сразу. Поэтому сюда можно вставлять ответы внутренних сервисов, фрагменты конфигураций и данные из выгрузок.
Почему в инструментах нет проверки живым компилятором?
Компилятор в браузере — это мегабайты кода, которые пришлось бы грузить на страницу ради одной кнопки: для TypeScript такой вариант громоздкий, для Python его нет вовсе. Поэтому проверка устроена иначе: текст разбирается своим кодом, и там, где ошибку вообще можно найти — незакрытая кавычка, лишняя запятая, непарная скобка, оборванный комментарий, — показывается место. Чего разбор не делает, так это проверки типов: он не знает ни вашего проекта, ни установленных версий. Сгенерированный код для компилятора обычный текст, поэтому прогнать его через `tsc`, `mypy` или проверку IDE нужно так же, как код, написанный руками.
Чем генератор TypeScript-типов отличается от генератора Python-моделей?
Только языком вывода, поэтому и стоят они рядом: вход у обоих один и тот же — образцы JSON. Один печатает объявления TypeScript, другой — классы Python, а выбор между ними диктует язык проекта, а не форма данных. Разница есть в одном: у Python-модели инструмент умеет и обратный ход — собрать пример JSON по уже написанному классу, — а генератор TypeScript только строит типы по образцам. Что именно попало в код — как названы поля, какие ключи стали необязательными, где собрались объединения типов — видно по отчёту на странице выбранного инструмента.
Чем pydantic v2 отличается от v1 в сгенерированных моделях?
Генератор выдаёт код под pydantic v2. Поле, чьё имя в Python отличается от ключа JSON, объявляется через `Field(alias=...)`, а разрешение заполнять модель и по имени, и по ключу задаётся строкой `model_config = ConfigDict(populate_by_name=True)`. В v1 то же самое писалось иначе: внутренним классом `Config` с `allow_population_by_field_name`, а разбор и сериализация назывались `parse_obj` и `dict()` — в v2 это `model_validate` и `model_dump`. То есть на v1 модель придётся подправить: переименовать опцию и методы. Если проект ещё на v1, проще взять вариант `dataclass` — он не зависит от версии pydantic.
Можно ли подогнать результат под наш стайлгайд?
В разумных пределах: у форматеров есть отступы (два пробела, четыре или таб), регистр ключевых слов SQL, положение запятой в списке; у генераторов — способ объявления модели и стиль имён полей. Настроек под конкретный линтер здесь нет и не планируется: привести проект к общему виду — задача prettier, black или sqlfluff, которые стоят у вас в репозитории, а не страницы в браузере. Практический приём такой: настроить параметры один раз под свой проект, посмотреть на странице, как это выглядит, и дальше гонять текст своим форматтером; для разового чтения чужого файла настроек хватает с запасом.