Сценарии жизненного цикла

Пакеты могут определять в поле scripts своего манифеста различные действия, которые должны выполняться при выполнении менеджером пакетов определённого рабочего процесса. Вот они:

Примечание о yarn pack: Несмотря на то, что yarn pack редко вызывается напрямую, он является ключевой частью Yarn. Каждый раз, когда Yarn должен получить зависимость из «сырцового» источника (например, репозитория Git), он автоматически выполнит yarn install и yarn pack для определения используемых файлов.

• prepack — сценарий жизненного цикла, вызываемый перед каждым вызовом yarn pack. Обычно здесь располагаются скрипты, которые компилируют пакет, например, транспилируют его исходный код.

• postpack вызывается сразу после yarn pack, независимо от успеха вызова. Обычно здесь удаляются артефакты сборки из рабочей директории (при этом, удаление необязательно).

• prepublish вызывается перед yarn npm publish и аналогичными командами (даже до упаковки пакета). Здесь необходимо проверить, что проект находится в хорошем состоянии. Поскольку он вызывается только при prepublish, в нём не должно быть побочных эффектов. В частности, не нужно транспилировать исходный код пакета в prepublish, так как пользователи, непосредственно использующие ваш репозиторий (например, через протокол git:), не смогут использовать ваш проект.

• postinstall вызывается после того, как изменения в дереве зависимостей пакета записаны на диск — например, после добавления, удаления или изменения зависимости или транзитивной зависимости. Он гарантированно вызывается в топологическом порядке (другими словами, postinstall ваших зависимостей всегда будет выполняться перед вашим).

  Для обратной совместимости preinstall и install вызываются как часть postinstall.

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

В частности, мы намеренно не поддерживаем произвольные pre и post хуки для пользовательских скриптов (например, prestart). Это поведение, унаследованное от npm, делало скрипты неявными, а не явными, что затрудняло понимание потока выполнения. Это также приводило к неожиданному выполнению, когда yarn serve также выполнял yarn preserve.

Примечание о postinstall

Сценарии postinstall имеют весьма ощутимые последствия для ваших пользователей. В большинстве случаев Yarn сохраняет установленные пакеты в своём кэше в их архивной форме и инструктирует Node загружать файлы непосредственно оттуда. Это приводит к значительно более мелким установкам и, в конечном итоге, к Zero-Installs.

К сожалению, скрипты postinstall нарушают эту модель, поскольку они сигнализируют Yarn о том, что этим пакетам, возможно, потребуется изменить свою директорию, что вынуждает их извлечь в физические места на диске, что приводит к более тяжёлым, медленным и менее стабильным установкам.

В зависимости от вашего случая использования, вот как можно избежать скриптов postinstall:

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

• Устойчивость проекта — важная тема, но суть в том, что мы не считаем скрипты postinstall жизнеспособным решением. Однако мы обязуемся предоставить специальное поле в package.json, которое будет сигнализировать менеджерам пакетов о том, что проект хотел бы общаться с пользователем интегрированным и уважительным способом.

Переменные окружения

При запуске скриптов и библиотек обычно доступны некоторые переменные окружения:

• $INIT_CWD представляет директорию, из которой был вызван скрипт. Это не то же самое, что cwd, которое для скриптов всегда равно ближайшему корню пакета.

• $PROJECT_CWD — корень проекта в файловой системе.

• $npm_package_name — имя пакета, содержащего исполняемый скрипт.

• $npm_package_version — его версия.

• $npm_execpath — путь к исполняемому файлу Yarn.

• $npm_node_execpath — путь к исполняемому файлу Node.

• $npm_config_user_agent — строка, определяющая используемую версию Yarn.

• $npm_lifecycle_event — имя скрипта или события жизненного цикла, если применимо.