gh-dash: сохранённые подборки PR для каждого репозитория

В gh-dash можно завести разделы с нужными PR и issue, чтобы не собирать поисковый запрос заново. Раздел получает название и фильтр GitHub Search в YAML. Например, в документации есть подборка открытых PR других авторов, обновлённых за последние две недели.

У таких разделов есть привязка к репозиторию. Если запустить дашборд из клона или задать GH_REPO, к фильтру без явного repo: по умолчанию добавится текущий репозиторий. Это удобно для одинаковых подборок в разных проектах, но само по себе не даёт общую очередь по всем репозиториям.

Нужен настроенный GitHub CLI с авторизацией. Начните с одного раздела и сравните выдачу с тем же поиском на GitHub. Пример фильтра есть в документации.

В ролике — демо из репозитория с интерфейсом v4.16.1.

Какие хуки запустятся? Сначала проверьте выборку в prek

Если в проекте уже настроен pre-commit, альтернативный раннер можно оценить на небольшой выборке файлов. Авторы prek заявляют совместимость с существующими конфигурациями и хуками. Сам раннер написан на Rust и управляет окружениями для проверок.

В prek run флаг --dry-run показывает выбранные хуки и файлы перед запуском проверок. Область можно ограничить шаблоном --glob для отслеживаемых файлов или перечислить пути через --files. Так проще заметить, что нужная проверка пропускает файл или захватывает лишнее.

Начните с копии рабочего проекта: изучите выборку, затем запустите проверки и сравните результат с привычным pre-commit. Совместимость стоит проверить на ваших хуках. Отдельный бинарник prek не отменяет зависимости и среды выполнения самих проверок. Способы установки есть в репозитории.

mkcert выдаёт сертификат для localhost. Сервер настраиваете вы

Для локальной разработки mkcert создаёт свой центр сертификации — CA — и выпускает сертификаты для localhost, тестовых доменов и адресов вроде 127.0.0.1. Это позволяет проверять приложение по HTTPS с локальной цепочкой доверия.

Здесь три отдельных действия: создать CA и добавить его в поддерживаемые хранилища доверия, выпустить сертификат с ключом, подключить файлы к веб-серверу. Флаг -install меняет хранилища доверенных корневых сертификатов. Сам mkcert HTTPS на сервере не включает. На другом устройстве доверие к CA нужно настраивать отдельно.

Используйте такой CA только для разработки, не для production и компьютеров конечных пользователей. Не передавайте rootCA-key.pem: этот ключ позволяет выпускать сертификаты, которым доверяет ваша машина, и перехватывать защищённые запросы. Порядок работы и ограничения — в README.

dekit запускает API, когда база сообщит о готовности

В примере dekit задача db ждёт ready.log: "ready to accept connections", а у api указано deps: [db]. dekit запустит зависимость и задержит API до появления этой подстроки в строке вывода базы. Это поиск текста, не регулярное выражение.

Условие ready нужно задать явно. Без него задача считается готовой сразу при старте процесса. Если зависимость — разовая задача job, запуск продолжится после её завершения с кодом 0. По умолчанию autostart выключен. В примере он включён у API, который запускает и свою зависимость.

dekit — преемник mprocs. Для проверки сценария нужен подготовленный проект с базой и API. Условия готовности управляют порядком запуска, а не непрерывной проверкой здоровья. Пример конфигурации и точные условия есть в документации.

git-absorb раскладывает правки после ревью по коммитам

В ветке несколько небольших коммитов, а замечания ревьюера касаются разных частей кода. git-absorb берёт только изменения из индекса Git и пытается подобрать для каждого фрагмента исходный коммит. Для найденных соответствий создаёт коммиты fixup!.

Основа подбора — перестановка патчей: меняется ли результат, если применить их в другом порядке. Это не понимание смысла исправления. По умолчанию поиск идёт по последним десяти коммитам, диапазон можно задать через --base. Фрагменты без подходящего коммита остаются в индексе с предупреждением.

Начните на одноразовой локальной ветке. Добавьте нужные правки в индекс, выполните git absorb и изучите новые коммиты через git log. Обычный запуск только создаёт fixup-коммиты. Их объединение с исходными через autosquash — отдельный этап с переписыванием истории. Механика и ограничения разобраны в README.

Из stdin в SQLite и обратно в JSON с sqlite-utils

Вывод команды можно передать в SQLite, выбрать нужные поля SQL-запросом и отдать результат следующему шагу пайплайна. У sqlite-utils memory база живёт в оперативной памяти. Для такого разового запроса не нужен постоянный файл базы.

В README показан пример для CSV с колонками name и age:

cat dogs.csv | sqlite-utils memory - "select name, age from stdin"

Знак - означает чтение стандартного ввода. Поэтому таблица в запросе называется stdin, а не dogs. По умолчанию результат выводится как JSON, флаг --csv переключает его на CSV.

Для входа поддерживаются CSV, TSV, JSON-объект или список объектов. Если автоопределение не подходит, формат задаётся явно, например stdin:csv. Начните с небольшого экспорта, который помещается в память. Форматы и параметры описаны в документации.

OpenAPI-спецификация как инструмент фронтенд-разработчика: практическое применение и типичные проблемы

Фронтендеры часто пишут типы и обёртки над API вручную, хотя бэкенд уже описал все эндпоинты в OpenAPI. Из этого файла можно получить почти весь код для работы с API.

В статье:
— Как найти исходную OpenAPI-спецификацию через Swagger UI или ReDoc.
— Как генерировать TypeScript-типы и использовать их с RTK Query, React Query и fetch.
— Как генерировать API-клиенты и типизировать BFF-роуты на Node.js с Express.
— Как создавать моковые данные и запускать mock-серверы по спецификации.
— Какие проблемы мешают кодогенерации и как автоматизировать подготовку спецификации с помощью openapi-modifier.

Последний пункт пригодится, если спецификация с ошибками: int вместо integer, лишние XML-ответы, внутренние пути. Автор показывает, как исправлять её на своей стороне своим инструментом openapi-modifier, не дожидаясь бэкенда.

https://habr.com/ru/articles/1105006/