Честный вопрос — отвечу честно, но сначала проверю, не завязаны ли на эти утилиты задачи mise или CI (чтобы рекомендация была про реальное использование, а не про мои ощущения):
Отвечу честно — без «на всякий случай оставим». Данные собраны, картина однозначная.
Ключевой факт, который снимает само заблуждение: мои встроенные инструменты поиска (Grep, Glob) используют собственные бинарники харнесса, а не то, что стоит в mise.toml репозитория. То есть ripgrep/fd/ast-grep, поставленные «чтобы Клоду было чем искать» — мне для поиска не нужны вообще. Я их не оттуда беру.
Что показала проверка:
- Ни одна задача mise и ни один workflow не ссылается на
fd,jq,yq,ripgrep,ast-grep,tokei,tldr. Единственный реально упоминаемый в CI —gh(релизы). gh,jq,yqу вас и так есть через homebrew (/opt/homebrew/bin) — они переживут удаление из этого репо. Остальные приходят из mise-шимов.
Вот честный разбор по каждому:
| Инструмент | Реально использую? | Вердикт |
|---|---|---|
java, node | — | Нужны сборке (Scala / Astro-доки) |
lefthook, betterleaks, scalafmt | — | Нужны хукам |
gh | Да, постоянно (PR, issues, ревью) | Оставить |
jq | Да, постоянно (gh api --jq, парсинг) | Оставить |
yq | Нет — YAML я правлю через Read/Edit | Убрать |
ripgrep | Нет — у меня встроенный Grep | Убрать* |
fd | Почти нет — у меня встроенный Glob | Убрать* |
ast-grep | Нет, ни разу | Убрать |
tokei | Нет, ни разу | Убрать |
tealdeer (tldr) | Нет, ни разу | Убрать |
ripgrep/fdмне не нужны, но это удобные CLI-утилиты лично для вас. Если вы ими в терминале не пользуетесь — убираем; если пользуетесь — оставьте для себя, ко мне это отношения не имеет.
Итого: смело удаляются yq, ast-grep, tokei, tealdeer (мёртвый груз — не использую ни я, ни автоматика). Плюс ripgrep/fd — по вашему желанию. Раздел «Agentic Tools» по сути схлопывается до gh + jq.
То же касается mise.toml в analytics (там из этого набора лежат yq и ripgrep).
Сказать «поехали» — и оформлю как полагается (issue → ветка → PR) в обоих репозиториях? Уточните только судьбу ripgrep/fd: убрать совсем или оставить вам для терминала?
Это уже не косметика, а реальная экономия ресурсов CI. Давайте разберём по-настоящему: важно не только почистить [tools], но и понять, как именно CI ставит инструменты — потому что даже после чистки CI может тянуть то, что нужно только локально (хуки, форматтер). Изучаю workflow-файлы обоих репозиториев и таску setup:
Важная находка уже здесь: основной ci.yaml вообще не использует mise — он ставит java и sbt напрямую через setup-java/setup-sbt. А вот release.yaml и publish.yaml используют jdx/mise-action@v4, который по умолчанию ставит весь список [tools]. Вот где утечка. Читаю всё внимательно:
ci.yaml (основная сборка на каждый PR) уже mise-free — java/sbt напрямую. А release.yaml/publish.yaml тянут весь [tools] через mise-action. Но раз основная сборка mise не трогает, «каждый раз» вы, скорее всего, видели в analytics — проверю его CI. И замечу аномалию: workflow зовёт mise run package:prepare, а такой задачи в mise.toml нет — проверю, не сломано ли:
Две важные находки:
package:prepare— это файловая задача в.mise/tasks/(не сломано, просто не в mise.toml).- Analytics CI уже оптимизирован! В
backend-ci.yamlесть прямой комментарий: «invoked directly so the CI job only needs the JVM toolchain instead of the full polyglot tool set from mise.toml» — то есть там sbt зовётся напрямую, mise-action нет.
Значит «каждый раз ставится всё» — это engine release.yaml/publish.yaml. Дочитываю их и файловые задачи, чтобы понять, что им реально нужно:
Дочитаю файловые задачи (они в подкаталогах) и publish.yaml, чтобы точно знать, что нужно release/publish:
Теперь картина полная. Ключевые факты:
package:prepareреально используетjq(формируетdist/package.json) — значитjqнужен и в CI, остаётся.mise run checkнужен только sbt+java, которые уже ставятся черезsetup-java/setup-sbt.- На ubuntu-runner’ах
jqиghпредустановлены — mise их дублирует. ci.yaml(каждый PR) mise не трогает; mise-action только вrelease/publish(редкие).
Прежде чем предлагать правки, сделаю полную карту: где во всех workflow обоих репозиториев вызывается mise-action/mise install/mise run — чтобы найти, где «каждый раз» ставится лишнее:
Полная карта собрана. Вывод чёткий:
- Только два workflow ставят весь набор mise-инструментов — engine
release.yamlиpublish.yaml(черезmise-action). Оба редкие (релиз/тег). - Все «каждый PR» пути уже чистые: engine
ci.yamlи analyticsbackend-ci.yamlзовут sbt напрямую, mise не трогают. (В карте analyticsbackend-ciпомечен[MISE]ложно — сработал на текст комментария.) - Философия «в CI — голый sbt, mise только локально» уже зафиксирована в комментарии
backend-ci.yaml. Логично распространить её на release/publish.
Проверю, что release/publish действительно проживут без mise: package:prepare — обычный bash-скрипт, и jq на ubuntu-runner’ах предустановлен. Сначала быстрая проверка analytics (нет ли там скрытого использования yq/ripgrep), потом локально прогоню package:prepare без mise:
Analytics чист — yq и ripgrep нигде не используются, можно удалять. Теперь главная проверка перед тем как трогать release-пайплайн: пройдёт ли package:prepare без mise. Прогоняю локально на engine (с восстановлением package.json после):
package:prepare без mise отработал идеально: оба шага EXIT=0, dist/ собрался со всеми файлами и корректным package.json (1.2.4), jq сработал из системного PATH. Дерево восстановлено. Подход подтверждён — release/publish проживут без mise полностью.
Оформляю как два PR (engine — чистка tools + два workflow; analytics — чистка tools). Начинаю с engine:
Теперь release.yaml — убираю mise-action, заменяю две mise run на прямые команды:
Теперь publish.yaml — те же две замены:
Проверяю, что в обоих workflow не осталось ссылок на mise, YAML валиден, и нет ли упоминаний в AGENTS.md, которые надо поправить:
YAML-проверка упала — надо понять почему (возможно, мой отступ, либо это известная причуда on: в PyYAML). Выясняю точную ошибку:
Ложная тревога — просто PyYAML не установлен (не сам YAML битый). Проверю через ruby и гляну на отступы в правках:
YAML валиден, отступы верны. Поправлю устаревшую строку в доках про релиз (там написано «Installs Java 25 and Mise»):
Коммичу engine-изменения и пушу:
Engine — PR #343. Теперь analytics (там CI уже mise-free, так что только чистка [tools]):
Оба PR открыты:
- engine #343 — чистка tools + удаление
mise-actionиз release/publish. - analytics #90 — удаление
yq,ripgrep.
Ставлю монитор на CI и ботов по обоим:
Монитор запущен. Подвожу честный итог по вашему вопросу — он оказался глубже, чем «лишние утилиты»:
Что выяснилось
Инструменты: из [tools] реально использую только gh и jq. Остальное (fd, yq, ripgrep, ast-grep, tokei, tealdeer) — мёртвый груз: мои встроенные Grep/Glob берут бинарники из харнесса, а не из mise репозитория. Так что предположение «поставим, вдруг Клоду нужно» не подтвердилось — спасибо, что спросили прямо.
А вот где была настоящая трата ресурсов CI (это важнее самих утилит):
ci.yaml(на каждый PR) и analyticsbackend-ci.yaml— уже чистые, ставят только JVM-тулчейн, mise не трогают.- А
release.yamlиpublish.yamlв engine тянулиjdx/mise-action→mise install→ весь список инструментов на каждый релиз/публикацию. Хотяmise run checkнужен только sbt, аmise run package:prepare— sbt + jq (jq и так предустановлен на runner’ах).
Что сделал (2 PR)
engine #343:
[tools]урезан до нужного.release/publishбольше не ставят mise-набор — зовут sbt напрямую, какci.yaml.package:prepareзапускается как обычный bash-скрипт.- Проверил локально с удалённым из PATH mise:
sbt rootJS/fullOptJS+ скрипт собралиdist/корректно (версия 1.2.4). Что публикуется — не изменилось. - Поправил устаревшее место в доках про релиз.
analytics #90: убраны yq, ripgrep.
ripgrep/fd на машине остаются (через homebrew/mise global) — из файлов репозиториев убраны, как вы и просили. Жду CI и ботов по обоим PR.
analytics #90 — CI зелёный. Жду engine #343 (там более существенные правки workflow) и комментарии ботов; монитор продолжает следить.
Оба PR зелёные. Проверю, не оставили ли боты замечаний (монитор ловил только inline-комментарии — проверю ещё и тела ревью):
Оба PR чистые, замечаний нет:
- engine #343 — CI зелёный, ботских комментариев нет.
- analytics #90 — CI зелёный, Gemini отметил «no issues».
Зафиксирую CI-философию в память — это пригодится для будущих правок пайплайнов:
Готово. Оба PR ждут вашего ревью и merge:
| PR | Что | Эффект |
|---|---|---|
| engine #343 | чистка [tools] + убрал mise-action из release/publish | релиз/публикация больше не ставят весь набор инструментов |
| analytics #90 | убрал yq, ripgrep | компактнее локальный mise install |
Главный вывод дня по вашему вопросу: проблема была не только в лишних утилитах, а в том, что mise-action в двух engine-workflow тянул весь полиглот-набор на каждый релиз. Теперь во всём экосистеме единый принцип — в CI sbt/npm зовём напрямую, mise только для локальной разработки. Записал в память, чтобы будущие правки пайплайнов держались этой линии.
Ваше чутьё было верным: значительная часть [tools] стояла «на всякий случай для Клода», а на деле ни я, ни сборка их не трогали. После merge — и файлы чище, и CI на релизах быстрее.
Подскажу на будущее: такие вещи удобно ловить периодически — если заметите в логах CI шаг, который ставит что-то не относящееся к сборке, это первый кандидат на проверку. На сегодня уборка в mise.toml завершена.
Хорошая мысль — после смены подхода в CI текст мог устареть. Сделаю сплошной поиск по обоим репозиториям. Важно отделить локальные упоминания mise run (они корректны — локально мы действительно используем mise) от утверждений, что CI/сборка/релиз используют mise (вот это теперь неверно).
Большинство упоминаний — это локальные команды (mise run check, format и т.д.), они корректны и должны остаться: локально mise мы используем. Но я вижу несколько мест, где текст описывает CI/релиз через mise — вот это устарело после #343. Читаю подозрительные места внимательно, начиная с самого важного — npm-packaging.md (там целый раздел «почему это в mise, а не в GitHub Actions»):
npm-packaging.md действительно устарел — раздел «Why This Lives in mise (Not in GitHub Actions)» с YAML-сниппетом run: mise run package:prepare больше не соответствует #343. При этом сам принцип (логика в одном скрипте) остаётся верным — просто CI теперь зовёт скрипт напрямую. Дочитываю остальные подозрительные места:
Картина полная. Нашёл реально устаревшие места (описывают CI/релиз/сборку через mise) и отделил их от корректных локальных упоминаний. Также вскрылись два до-существовавших неточностей про «mise ставит sbt», которые тоже стоит освежить. Читаю участки под правку:
Теперь делаю все engine-правки (на ветке #343, т.к. они — прямое следствие изменения workflow):
Проверю mermaid-блок — я добавил end, но в оригинале после CI-подграфа уже мог быть свой end:
Так и есть — лишний end на строке 25. Убираю:
Теперь главный файл — npm-packaging.md. Переписываю раздел про CI и frontmatter, сохраняя верный принцип «логика в одном скрипте»:
Собираю engine-доки (проверка mermaid и ссылок), затем коммичу в #343:
Engine #343 обновлён доками. Теперь analytics: в backend/README.md два устаревших места — «mise install ставит sbt» (sbt в analytics через mise не ставится) и ручной export GITHUB_ACTOR/GITHUB_TOKEN (после #88 build.sbt берёт токен из gh сам). Это отдельная тема от чистки tools — делаю отдельным PR от main:
PR #92 открыт. Финальная проверка — не осталось ли где-то ещё утверждений, что CI/сборка/релиз идут через mise. Заодно сверю engine CONTRIBUTING.md (там был release-блок):
Нашёл ещё одно явно устаревшее место: engine CONTRIBUTING.md, раздел «6. Merge & Auto-Publish» — описывает CI-публикацию через mise run check / mise run js:build / mise run package:prepare. После #343 это неверно. Остальные срабатывания — корректные (локальные команды, описания лейбла ci-cd, мои уже-исправленные строки). Правлю CONTRIBUTING:
Финальная проверка чистая: остался только CONTRIBUTING.md:10 («run mise run check before opening a PR») — это локальная инструкция, корректна.
Ставлю монитор на обновлённый #343 и новый #92:
Документация выметена от устаревших «CI/сборка через mise». Итог сверки по обоим репозиториям:
Что исправил (всё — реальные claims, что CI/релиз/сборка идут через mise):
engine — добавил в #343:
npm-packaging.md— раздел «Why This Lives in mise (Not in GitHub Actions)» и YAML-сниппетrun: mise run package:prepare. Переписал: принцип «логика в одном скрипте» сохранён, но CI теперь зовёт скрипт напрямую.releases.md— шаг NPM-компиляции (былmise run package:prepare).code-reviews.md— диаграмма качества больше не подразумевает, что CI идёт черезmise run check; критерий ревью workflow → «no redundant tool installs».CONTRIBUTING.md— раздел auto-publish (былmise run check/js:build/package:prepare).README.md— getting-started:mise installставит mise-тулчейн, а sbt — черезmise run setup(раньше sbt и «Scala CLI» ошибочно числились заmise install).
analytics — отдельный #92:
backend/README.md— «mise installставит sbt» (sbt ставится отдельно) и устаревший ручнойexport GITHUB_ACTOR/GITHUB_TOKEN(после #88 build.sbt берёт токен изgh).
Что намеренно НЕ трогал — корректные локальные упоминания: mise run check/format/console как локальные команды, «Developer Workflows (Mise)», описание лейбла ci-cd («…or mise configuration»). Локально mise мы используем — это правда.
Теперь открыто три PR: engine #343 (код+доки), analytics #90 (tools) и #92 (доки). Монитор следит за CI и ботами по обновлённым.
Один побочный момент на ваше усмотрение: analytics backend-ci.yaml, похоже, гоняет полный прогон тестов даже на изменение backend/README.md — если хотите, отдельно добавлю path-фильтры, чтобы doc-only правки не запускали sbt. Но это уже за рамками сегодняшней задачи.
engine #343 — CI снова зелёный после доков. Жду analytics #92.
Оба зелёные. Проверю, не оставили ли боты замечаний на обновлённых PR:
Все три PR зелёные, замечаний от ботов нет (Gemini по #90 — «no feedback», по #92 — нейтральное резюме без претензий, по #343 — пусто).
Итог сверки документации
Прошёлся по всем .md/.mdx обоих репозиториев, отделил устаревшее (CI/релиз/сборка через mise) от корректного (локальные команды) и поправил только первое:
| PR | Что освежил |
|---|---|
| engine #343 | npm-packaging.md, releases.md, code-reviews.md, CONTRIBUTING.md, README.md — все описания, где CI «строит через mise» |
| analytics #90 | чистка [tools] (yq, ripgrep) |
| analytics #92 | backend/README.md — sbt ставится отдельно; убран устаревший ручной экспорт токенов |
Ключевой принцип теперь единообразно отражён и в коде, и в текстах: в CI — sbt/npm напрямую, mise только для локальной разработки. Корректные локальные упоминания (mise run check/format, «Developer Workflows (Mise)», лейбл ci-cd) намеренно оставил — они правдивы.
Все три PR ждут вашего ревью и merge. Напомню про побочный момент (не блокер): analytics backend-ci.yaml, судя по всему, запускает полный прогон тестов даже на doc-only изменения вроде #92 — если захотите, отдельной мелочью добавлю path-фильтры. На сегодня документация свежая и согласована с реальностью сборки.