С выпуском следующей основной версии Yarn 2.0 (кодовое имя berry) ее разработчики / сопровождающие вводят множество новых функций. И одна из функций, от которой пытаются избавиться, - это каталог infamousnode_modules.

Присоединяйтесь к Yarn 2.0's Plug’n’Play!

Головная боль `node_modules`

Всякий раз, когда вы хотите установить зависимости вашего приложения, упомянутые в файле package.json, вы должны запустить:

yarn install

… ..И альт! Вы получаете огромный node_modulesdirectory в корневом каталоге вашего приложения. Это большой коллективный пул всех пакетов и библиотек, которые необходимы вашему приложению и его зависимостям для работы. Но проблемы возникают из-за гигантского размера каталога:

  • При попытке получить доступ к любой зависимости в приложении задача Node - искать файлы и извлекать их. И вот как это делает Node:

Этот файл существует здесь? Нет? Тогда давайте посмотрим на родительский node_modules. Он здесь существует? Все еще нет? Жаль ... ', и продолжайте, пока не найдете нужный.

  • Создание огромного каталога занимает в среднем 70% времени команды yarn install. Даже наличие уже установленных пакетов не поможет, так как заранее необходимо выполнить алгоритм сравнения.
  • Поскольку это операция ввода-вывода для размещения нескольких пакетов, практически нет возможности оптимизировать процесс и сэкономить время.
  • Даже во время выполнения разрешение узла требует времени для получения пакетов / библиотек, что влияет на время загрузки приложения.
  • Конструкция node_modules не позволяет менеджерам пакетов выводить установленные пакеты. Это приводит к тому, что некоторые пакеты создаются несколько раз в памяти.

Пряжа PnP - режим Plug’n’Play

Чтобы преодолеть это узкое место node_modules, yarn представил режим Plug’n’Play для управления зависимостями.

Хотя эта функция была представлена ​​ранее, yarn 2.0 вместо этого решил придерживаться этого режима по умолчанию.

В основе этого режима лежит следующая идея: Когда yarn знает дерево зависимостей и устанавливает пакет для вашего приложения, почему бы yarn также не взять на себя поиск и извлечение пакетов?

Таким образом, в режиме PnP весь node_modules удаляется, и yarn создается один файл с именем .pnp.js. Этот файл содержит карту, связывающую имя и версию пакета с местом на диске, и другую карту, связывающую имя и версию пакета с его набором зависимостей.

Таким образом, yarn становится обязанностью сообщить Node, где именно искать необходимые файлы.

Преимущества файла .pnp.js

  • Поскольку создается только один текстовый файл вместо десятков тысяч, установка теперь происходит практически мгновенно.
  • Установка становится более стабильной и надежной из-за уменьшения количества операций ввода-вывода, которые подвержены сбоям (особенно в Windows).
  • Более быстрый запуск приложения, потому что разрешение узла не должно повторять иерархию файловой системы почти так же часто, как раньше (и скоро уже не придется этого делать!).

Как начать использовать режим PnP?

Хотя PnP по умолчанию входит в yarn 2.0, вы также можете опробовать эту функцию в yarn 1.x версии. Чтобы включить режим PnP, вам необходимо включить флаг installConfig.pnp в вашем package.json:

А затем простой запуск yarn install после этого удалит ваш node_modules каталог и поместит .pnp.js файл.

Недостатки

В то время как режим PnP действительно кажется неуловимой серебряной пулей от проблемы узкого места к проблемам node_modules, он, тем не менее, вызвал серьезные недоумения и вызвал разногласия среди сообщества относительно того, следует ли использовать этот режим по умолчанию в новой версии пряжи или отклонить весь yarn 2.0 вместе. Основную причину этого раскола можно объяснить:

  • Хотя режим PnP полностью удаляетnode_modules, все еще существуют некоторые основные существующие библиотеки / пакеты, такие как Flow и React Native, которые зависят от каталога node_modules. Это создает проблему совместимости yarn 2.0 с этими широко используемыми библиотеками.
  • Даже если существующий проект не использует эти библиотеки, миграция не проста и требует дополнительных подключаемых модулей, чтобы преобразователи пакетов в Webpack и Typescript PnP были совместимы.

В то время как yarn 2.0 предоставляет метод отключения режима PnP путем включения встроенного node-modules plugin путем добавления следующего в ваш локальный .yarnrc.yml файл перед запуском нового yarn install:

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

Более того

Хотя есть некоторые проблемы с переключением в режим PnP в вашем существующем приложении yarn 2.0, но его можно использовать при создании приложений с нуля. Вы должны руководствоваться девизом:

Если вы можете использовать функцию Plug’n’Play, вы хотите использовать ее в своем приложении.

Причина, по которой PnP поставляется по умолчанию в yarn 2.0, заключается в том, что режим PnP является частью общего плана yarn по созданию приложений NodeJS с нулевой установкой с одной конкретной целью:

Чтобы сделать проекты Node максимально стабильными и быстрыми, удалив из уравнения основной источник энтропии: сам Yarn.

Это будет объяснено позже в отдельной статье.