PHP PHP · 25 вопросов · ~70 мин · ⏱ Таймер 10:00 · Средний ·

Composer и зависимости

Здесь нужно понимать, почему одна и та же команда даёт разные последствия в разработке и при выпуске. Сценарии охватывают ограничения версий, composer.lock, PSR-4, аудит зависимостей и воспроизводимую установку.

Отвечено: 0 из 25

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. Отделяйте изменение набора зависимостей от установки уже зафиксированных версий. На тест отведено 70 минут.

Вопрос 1 из 25

Где должна находиться библиотека журналирования, используемая рабочим кодом?

{
  "require": {
    "php": "^8.2",
    "psr/log": "^3.0"
  },
  "require-dev": {
    "phpunit/phpunit": "^11.0"
  }
}

В repositories без require Только в scripts В config.platform В require-dev В require

Вопрос 2 из 25

Что означает запись php: ">=8.2"?

{
 "require": {"php": ">=8.2", "psr/log": "^3.0"}
}

Проект объявляет минимально допустимую версию интерпретатора Запись разрешает 8.2, но запрещает любые более новые версии Это версия формата composer.json, а не требование платформы Все пакеты проекта обязаны быть написаны именно для PHP 8.2 Composer загрузит отдельный интерпретатор PHP в каталог vendor

Вопрос 3 из 25

Для чего предназначен раздел scripts?

{
  "scripts": {
    "test": "phpunit",
    "check": ["@test", "phpstan analyse"]
  }
}

Для фиксации контрольных сумм всех файлов установленных пакетов Для команд жизненного цикла и сценариев проекта Для хранения секретов окружения и паролей внешних систем Для размещения исходного PHP-кода, который Composer выполнит как библиотеку Для объявления PSR-4-префиксов и пространств имён классов

Вопрос 4 из 25

Что неверно в хранении пароля репозитория прямо в composer.json?

Composer не поддерживает строки Секрет попадёт в систему версий вместе с файлом Пароль автоматически станет namespace JSON запрещает двоеточия Пакет перестанет автозагружаться

Вопрос 5 из 25

Что проверит composer validate?

composer validate --strict

Схему базы данных и соответствие миграций установленным пакетам Синтаксис и типы всех PHP-файлов, перечисленных в autoload Доступность каждого HTTP-маршрута после запуска приложения Структуру composer.json и согласованность с lock-файлом Надёжность паролей и корректность переменных окружения

Вопрос 6 из 25

Какой диапазон обычно допускает ^2.3?

{
  "require": {
    "vendor/library": "^2.3"
  }
}

Любую версию от 2.3 без верхней границы От 2.0 до 2.3 включительно Только версии 2.3.x Только 2.3.0 Версии от 2.3.0 до, но не включая 3.0.0

Вопрос 7 из 25

Зачем коммитить composer.lock у приложения?

composer install --no-interaction --prefer-dist

Чтобы composer install перестал читать ограничения из composer.json Чтобы install выбирал те же версии зависимостей в разных окружениях Чтобы хранить исходный код каждого пакета вместо каталога vendor Чтобы lock-файл служил резервной копией базы и пользовательских данных Чтобы скрыть перечень зависимостей от разработчиков и системы сборки

Вопрос 8 из 25

Чем composer update отличается от composer install при наличии lock-файла?

install всегда ставит самые новые версии update только проверяет синтаксис update меняет lock, install ставит зафиксированные версии install удаляет composer.lock Различий нет

Вопрос 9 из 25

После проверки зависимостей решили обновить только monolog/monolog вместе с пакетами, которые должны измениться из-за него. Какая команда минимизирует область пересчёта?

composer show monolog/monolog
composer outdated --direct

composer update --with-all-dependencies composer require monolog/monolog --no-update composer update monolog/monolog --no-install composer install monolog/monolog composer update monolog/monolog --with-all-dependencies

Вопрос 10 из 25

Почему ограничение "*" опасно для ключевой библиотеки?

Она разрешает только локальный путь Composer трактует её как версию 0 Пакет нельзя удалить Она допускает несовместимые основные версии Звёздочка отключает пакет

Вопрос 11 из 25

Что делает composer dump-autoload -o?

composer dump-autoload -o

Обновляет версии всех зависимостей до последних допустимых Удаляет vendor и заново устанавливает пакеты по lock-файлу Перестраивает и оптимизирует таблицы автозагрузки Проверяет структуру таблиц базы, используемых пакетами проекта Запускает встроенный веб-сервер с оптимизированной автозагрузкой

Вопрос 12 из 25

Когда раздел autoload.files уместен?

{
  "autoload": {
    "files": ["src/functions.php"]
  }
}

Только для тестов PHPUnit Для переменных окружения с паролями Для функций или файла, подключаемого всегда Для хранения изображений Для каждого класса PSR-4

Вопрос 13 из 25

Почему после добавления класса classmap может потребоваться dump-autoload?

Класс обязан быть перезапущен в базе Оптимизированная карта ещё не знает новый путь PHP кэширует имена в cookie Composer запрещает новые файлы classmap работает только один раз навсегда

Вопрос 14 из 25

Зачем в первой строке подключается vendor/autoload.php?

require dirname(__DIR__).'/vendor/autoload.php';
$app = new App\Kernel();

Все пакеты загрузятся при первом echo Только функции перестанут работать PHP скачает пакет из сети Composer сам подключит файл через PHP.ini Чтобы зарегистрировать загрузчик классов Composer

Вопрос 15 из 25

Чем classmap-authoritative отличается от обычной оптимизации?

Разрешает автозагрузку классов с сетевых путей вне проекта Он доверяет classmap и не ищет неизвестные классы по PSR-4 Сразу загружает в память все классы, перечисленные в classmap Режим автоматически обновляет пакеты при каждом неизвестном имени класса Он отключает OPcache, чтобы карта классов всегда читалась с диска

Вопрос 16 из 25

Что показывает composer audit?

composer audit --locked

Время выполнения каждого метода из установленных пакетов Ошибки предметной логики, которые проявились в тестах приложения Пароли, сохранённые в базе и переменных окружения Уязвимости и заброшенные пакеты в графе зависимостей Покрытие строк и ветвей тестами PHPUnit

Вопрос 17 из 25

Уязвимый пакет транзитивный. Как понять, кто его привёл?

composer why symfony/http-foundation

php -m composer dump-env composer archive composer why vendor/package composer init vendor/package

Вопрос 18 из 25

Почему нельзя без проверки применять composer update ко всему production-проекту?

Update всегда очищает базу Команда удаляет PHP Composer не проверяет хеши Пакеты устанавливаются только в память Обновится широкий граф с возможным изменением поведения

Вопрос 19 из 25

Что сделать с давно заброшенной библиотекой, даже если уязвимость пока не опубликована?

Заранее оценить замену и сократить зависимость Навсегда закрепить старую версию Скрыть предупреждение Composer Переименовать пакет локально Добавить его в require-dev

Вопрос 20 из 25

Как безопаснее проверять новый выпуск зависимости?

Удалить lock и надеяться на совместимость Проверить только страницу входа Сразу заменить vendor на сервере Обновить отдельно, изучить изменения и прогнать проверки Отключить журнал ошибок

Вопрос 21 из 25

Команда сообщает conflict. Что показывает composer why-not package 3.0?

composer why-not vendor/package 3.0

Какие файлы пакета заражены или изменены локально Почему текущая версия PHP не запускает bootstrap приложения Какие ограничения мешают установить указанную версию Кто является автором и сопровождающим пакета Почему выбранный пакет медленно работает под нагрузкой

Вопрос 22 из 25

Почему наличие vendor в рабочем каталоге разработчика не доказывает корректность зависимостей?

rm -rf vendor
composer install --no-dev --prefer-dist

PHP читает пакеты только из облака Composer не использует vendor vendor всегда пуст Все файлы удаляются после запроса В vendor могут остаться файлы вне lock-файла

Вопрос 23 из 25

Что полезно запускать в непрерывной проверке?

Только удаление lock-файла и повторное разрешение зависимостей Только phpinfo, подтверждающий наличие интерпретатора composer validate, audit, чистую установку и тесты Только composer show в уже загрязнённом каталоге vendor Только печать composer.json без проверки схемы и lock-файла

Вопрос 24 из 25

Что делает composer diagnose?

Исправляет весь PHP-код Создаёт миграции базы Переписывает зависимости на latest Проблемы окружения, сети и настроек Composer Измеряет покрытие

Вопрос 25 из 25

После install класс не найден только в production с --no-dev. Наиболее вероятная причина?

Параметр --no-dev удаляет все классы пространства имён App composer.lock не читается на Linux при установке без dev-пакетов Production-режим PHP не поддерживает пользовательские namespace Рабочий код ошибочно зависит от пакета или autoload-dev --no-dev отключает сам интерпретатор для файлов рабочего приложения

Ответьте на все 25 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу