В последние годы наблюдается распространение высококачественных инструментов управления пакетами для широкого спектра языков веб-разработки. Драгоценные камни Ruby всегда были ключевым преимуществом этой платформы, обеспечивая своего рода легендарную производительность разработчиков, которая теперь, к счастью, широко доступна независимо от платформы.

Но управление зависимостями само по себе является искусством, о котором многие мало задумываются, пока что-то не сломается катастрофически, и разработчики не смогут исправить какой-нибудь малоизвестный зависимый модуль, о котором они даже не подозревали, как катастрофа с левой панелью сделали для разработчиков Node.js ранее в этом году.

Если, как обнаружили разработчики в тот день, ваш проект настолько силен, насколько сильна ваша самая слабая зависимость, разумно иметь представление о том, что вы получаете, от кого и как вы это делаете.

Такие громкие имена, как Facebook, как и все остальные, были застигнуты врасплох, и желание контролировать свои зависимости, несомненно, привело к созданию пряжи, новый менеджер пакетов JavaScript, который нам тоже очень нравится.

Работая вместе с npm, предназначенным для замены, Facebook рекламирует следующие преимущества:

  1. Скорость
  2. Надежность
  3. Безопасность

Последние два преимущества связаны с файлом .lock, с которым, вероятно, знакомы пользователи PHP в Composer, но которого нет в npm:

Волшебная подсказка за этим? Всякий раз, когда вы запускаете yarn install, файл yarn.lock имеет приоритет над файлом package.json.

Если файл yarn.lock существует, будут использоваться определенные в нем (точные) версии.

Если yarn.lock не существует, будут использоваться (свободно определенные) версии, определенные в package.json, и будет сгенерирован yarn.lock.

Управление пакетами на стороне PHP кажется сравнительно безопасным и управляемым. PHP имеет обширную стандартную библиотеку, и мы вряд ли будем использовать 100 пакетов для загрузки простого приложения. Гораздо проще изучить ландшафт зависимостей приложения и понять, что там есть и почему.

Функции, которые пряжа стремится предоставить разработчикам JavaScript, такие как этот файл блокировки, всегда были частью нашего рабочего процесса. Так что, возможно, вы не думали об этом слишком глубоко.

На самом деле, у вас могут возникнуть вопросы, которые стоит рассмотреть.

Почему важен файл composer.lock

Как именно это связано с composer.json? Должен ли я зафиксировать его в системе контроля версий? Как я справляюсь с конфликтами?

Правильное управление зависимостями PHP

Что я должен использовать как зависимость, а что как зависимость разработчика? Должен ли я изменить зависимость, как правильно это сделать? Как оптимизировать использование моего пакета для производства?

Прежде всего, помните о том, что вы втягиваете, что втягивает то, что вы втягиваете, и о возможностях, которые предлагает ваш инструментарий, чтобы позволить вам управлять ими, чтобы сегодняшнее удобство не привело вас в неудобную ситуацию в будущем.