«Как я ускорил установку PHP-зависимостей в 5 раз с помощью Go»

PHP-разработчик решил проверить простую гипотезу:
что будет, если убрать PHP-runtime и сделать установку зависимостей по-настоящему параллельной?

Результат — go-composer: совместимый (почти) с Composer инструмент, написанный на Go.

Почему обычный Composer медленный
Коротко и без иллюзий:

• интерпретируемый PHP
• последовательная загрузка пакетов
• тяжёлый runtime даже для простых операций
• медленный SAT-resolver зависимостей

В CI это превращается в минуты ожидания.

Что сделал go-composer
Ключевая идея — конкурентная модель Go:
• параллельная загрузка всех пакетов (goroutines)
• один скомпилированный бинарник (~10 MB)
• отсутствие PHP runtime overhead
• эффективная работа с памятью

Архитектура (упрощённо)
Пайплайн выглядит так:
1️⃣ Парсинг composer.json / composer.lock
2️⃣ Resolver строит граф зависимостей
3️⃣ Пакеты загружаются параллельно
4️⃣ Генерируется совместимый autoload
5️⃣ Результат — привычный vendor/

Самое интересное внутри
Parallel Installer — сердце ускорения
Каждый пакет:

• скачивается
• проверяется по SHA-256
• распаковывается
• добавляется в lock

И всё это — одновременно, а не по очереди.

Бенчмарки (MacBook M1, 300 Mbps)
Результаты выглядят болезненно честно:
• Monolog (3 пакета): 3–4× быстрее
• Symfony app (36 пакетов): 4–5× быстрее
• Laravel app (80+ пакетов): до 5× быстрее

Что уже работает
✅ composer.json / composer.lock (чтение)
✅ semver (^, ~, >=, ||, *)
✅ PSR-4 / PSR-0 / classmap
✅ Packagist (P2 API)
✅ проверка хэшей

Что не работает (и это важно)
❌ Composer scripts
❌ Composer plugins
❌ VCS-репозитории
❌ Private Packagist
❌ полная совместимость composer.lock

👉 в продакшен — пока нет

Почему появился go-composer.lock
Полной совместимости с composer.lock пока нет, поэтому:
• если lock есть — используется он
• если нет — создаётся go-composer.lock
• флагами можно управлять поведением

Это честный технический компромисс.

👉 Хабр

Библиотека пхпшника