Hacker News Digest

В работе с monorepo, где ежедневно делаются сотни коммитов, тесты внезапно начали проваливаться. Проблема была в изменении конфигурационного файла, который ссылался на неверный аккаунт, но найти виновника среди множества коммитов вручную было невозможно. Тогда коллега применил git bisect - инструмент, использующий бинарный поиск для локализации проблемного коммита. Это позволило точно определить, где именно был внесен сбойный код, после чего откат этого коммита восстановил работоспособность системы.

В статье приведен наглядный пример репозитория с функцией сложения, где намеренно введена ошибка - преобразование аргументов в строки. Запуск git bisect start, указание "плохого" и "хорошего" коммитов, затем git bisect run ./test_script.sh автоматически проверяет промежуточные версии. Инструмент последовательно тестирует коммиты, сокращая количество проверок вдвое на каждом шаге, и точно находит первый сбойный коммит, где функция add начала возвращать строку вместо числа.

• git bisect is a powerful tool for pinpointing the exact commit that introduced a bug, especially in large or poorly tested codebases.
• Its real value is in narrowing the search space when you lack the tests or architecture to reason about the code, not in replacing proper testing or code review.
• The discussion exposed a cultural divide: some developers see bisect as a last-ditch rescue tool for when tests or architecture have already failed, while others argue that if you need it, your process has already failed.
• Several commenters pointed out that if you have to reach for bisect, you probably lack tests, logging, or a clear commit history, and the real fix is to improve those, not to rely on bisection.
• The thread also surfaced the point that bisection is only useful if you can reliably detect the bug in every commit; if the bug is non-deterministic or only shows up in production, the tool becomes much less useful.

Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

Ключевое преимущество — автоматическое определение контекста и зависимостей между проектами, что сокращает рутинные операции. Интеграция с существующими инструментами вроде npm scripts делает переход плавным. Такой подход экономит время и снижает вероятность ошибок при ручном управлении задачами.

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.

Автор успешно удалил около 120 неиспользуемых зависимостей в Nx-монополии, сократив время установки на минуту и уменьшив количество уязвимостей. Для этого он использовал инструмент Knip вместо устаревшего depcheck, так как он лучше работает с современными монополями и анализирует импорты и конфиги. Knip выдал список потенциально ненужных пакетов, но около 40% из них оказались ложными срабатываниями — например, зависимости использовались в скриптах, конфигах Jest или CSS.

Процесс включал удаление кандидатов, последующую проверку сборки, тестов и запуска приложений, а затем восстановление пакетов, которые оказались нужны, с добавлением их в ignore-лист Knip. Автор настроил конфиг под монополию, игнорируя специфичные для проектов ложные срабатывания. Изменения были мержены одной партией в тихое время с предварительным деплоем в preview-ветку для проверки. В будущем планируется интегрировать Knip в CI для предотвращения накопления мусора.

• Обсуждаются причины накопления неиспользуемых зависимостей: невнимательность разработчиков, множественные рефакторинги, устаревшие библиотеки в монорепозиториях и автоматическое добавление пакетов без контроля.
• Участники отмечают, что инструменты вроде Knip помогают выявлять мертвые зависимости и файлы, но не оценивают качество кода, и окончательное решение остается за человеком.
• Экосистема и практики разработки (например, pip freeze или npm install без проверки) поощряют накопление лишних пакетов.
• В больших и старых проектах, особенно с микросервисами и смешанными стеками, "хлам" накапливается быстро из-за миграций и отсутствия регулярной очистки.
• Некоторые видят в постоянной борьбе с кликбейтом и переименованиях заголовков раздражающий и непродуктивный аспект обсуждений.

• Обсуждаются строгие правила CRAN для R-пакетов, требующие обратной совместимости и тестирования всех зависимых пакетов при обновлении, что сравнивают с монорепозиторием.
• Поднимаются проблемы других экосистем (Python, npm), где распространены ломающие изменения и конфликты зависимостей, и отмечается стабильность R.
• Участники спорят о практичности подхода CRAN: одни видят в нём бремя для разработчиков, другие — выгоду для научной воспроизводимости и пользователей.
• Предлагаются альтернативы и обходные пути, такие как полное форкирование, версионирование API или контейнеризация.
• Отмечается уникальная философия R-сообщества, ориентированная на статистиков, а не на разработчиков, что объясняет такие жёсткие требования.