Поскольку pnpm становится все более и более популярным, я считаю, что все слышали все больше и больше раз Сегодня мы также узнаем вместе, в чем заключается магия pnpm , которая высоко ценится.
Оглавление
1. Принцип установки npm/yarn
Что происходит при установке npm/yarn ? В основном он разделен на две части: первая: как пакет достигает node_modules , а вторая: как node_modules внутренне управляет зависимостями;
После выполнения команды сначала будет построено дерево зависимостей, а затем пакет под каждым узлом пройдет четыре шага:
- Разобрать интервал версии зависимого пакета до определенного номера версии
- Загрузите соответствующий зависимый пакет tar на локальное автономное зеркало.
- Распаковать зависимости от автономного зеркала в локальный кеш
- Скопируйте зависимости из кеша в каталог node_modules текущего каталога
Затем соответствующий пакет прибудет в node_modules проекта .
Итак, какая структура каталогов у этих зависимостей в node_modules ? То есть как выглядит дерево зависимостей, которое мы ввели выше? Это зависит от подробного объяснения ниже, разные версии разные!
Два, нпм
Начнем с npm2 согласно истории развития инструментов управления пакетами npm :
Используйте инструмент управления версиями узла , чтобы уменьшить версию узла до 4 , тогда версия npm будет 2.x.
Затем мы создаем новую демонстрацию, выполняем npm init -y и быстро создаем package.json .
Затем выполните npm install express , после чего будет загружен экспресс-пакет и его зависимости:
Расширьте экспресс, у него также есть node_modules
Развернув еще несколько слоев, мы обнаружим, что у каждой зависимости есть свои node_modules
То есть node_modules npm2 являются вложенными .
node_modules
└─ экспресс
├─ index.js
├─ package.json
└─ node_modules
└─ accepts
├─ index.js
└─ package.jsonЭту структуру мы назвали деревом зависимостей выше !
Теперь среди акцептов есть зависимости, а дальше вложенность продолжится. Только представьте, что не так с такой конструкцией?
- Уровень зависимости слишком глубокий, что приводит к фатальной проблеме, заключающейся в том, что длина пути к файлу Windows достигает 260 символов, поэтому вложенность превысит предел длины пути Windows .
- Установлено большое количество дубликатов пакетов, а размер файла очень большой. Например, если в статистическом каталоге экспресса есть foo , и оба зависят от одной и той же версии Lodash , то Lodash будет установлен в node_modules двух , то есть повторная установка, которая будет занимать относительно большое место на диске .
- Экземпляры модуля не могут использоваться совместно. Например, в React есть некоторые внутренние переменные.React, представленный в двух разных пакетах, не является одним и тем же экземпляром модуля, поэтому внутренние переменные нельзя использовать совместно, что приводит к некоторым непредсказуемым ошибкам.
В то время npm еще не решил ее, и сообщество придумало новое решение, которым стала пряжа :↓
Три, пряжа
Как пряжа решает проблему повторяющихся зависимостей и длинных вложенных путей?
Flattening , то есть все зависимости больше не вложены слой за слоем, а все на одном слое, чтобы не было проблемы повторяющихся зависимостей, и не было проблемы слишком длинных путей;
Мы удалили node_modules , переустановили с помощью yarn и выполнили yarn add express :
В настоящее время node_modules выглядит так:
Все выложены на первом этаже, и большинство следующих пакетов не имеют node_modules второго уровня :
Все зависимости выравниваются в node_modulesкаталоге, и больше нет глубокой вложенности. Таким образом, при установке нового пакета, в соответствии с механизмом node require, он будет продолжать node_modulesискать его на верхнем уровне.Если будет найдена та же версия пакета, он не будет переустанавливаться, что решает проблему повторной установки. установка большого количества пакетов, а уровень зависимости не изменится.слишком глубокий.
Но если вы расширите еще несколько зависимых пакетов, вы узнаете, почему все еще существует вложенность?
Поскольку у пакета может быть несколько версий, обновить можно только одну из них, поэтому при обнаружении разных версий одного и того же пакета позже используется метод вложения.
После того, как npm был позже обновлен до 3 , он также принял эту схему мощения, котораяочень похожа на yarn . Конечно, yarn также реализует yarn.lock для блокировки версии, и эта функциятакже реализуется npm .
Но и yarn , и npm используют проложенное решение, так что нет ли проблем с этим решением?
Нет, у него еще много проблем, давайте разбираться:
- В зависимости от неопределенности конструкции .
- Сам алгоритм выравнивания очень сложен и занимает много времени.
- Призрачные зависимости (с точки зрения непрофессионала:к пакетам, для которых не объявлены зависимости, можно получить незаконный доступ )
Позже и то, и другое легко понять, но как понять неопределенность первого пункта?
Если теперь проект зависит от двух пакетов Barry и Lishen, зависимости этих двух пакетов следующие:
Итак, когда устанавливается npm/пряжа, что происходит после выравнивания?
Это так?
Или это так?
Ответ таков: оба варианта возможны, в зависимости от позиций Barry и Lishen в package.json , если Barry объявлен первым, это предыдущая структура, в противном случае — последняя структура. Вот почему зависимость вызовет проблему «неопределенности» , из- за которой родился упомянутый выше файл блокировки , будь то package-lock.json (доступен после npm 5.X, то есть npm3 ) или yarn.lock , это все для того, чтобы после установки была создана определенная структура node_modules .
Так как же pnpm решает эти две проблемы?
4. ч/млн
Помните , почему npm3 и yarn должны сглаживать node_modules ? Не потому ли, что одна и та же зависимость будет копироваться несколько раз, а путь слишком длинный, значит, проблема под windows?
Что делать, если вы не скопируете его, например, через ссылку .
Во-первых, давайте представим link , то есть мягкие и жесткие ссылки.Это механизм, предоставляемый операционной системой.Жесткие ссылки - это разные ссылки на один и тот же файл, а мягкие ссылки - для создания нового файла, а содержимое файла указывает на другой путь . Конечно, использование этих двух ссылок аналогично.
Что, если не копировать файлы, а просто сохранить копию содержимого npm-пакета в глобальном хранилище, а остальные места связать?
Таким образом, не будет лишней траты дискового пространства на многократное копирование и не будет проблем со слишком длинными путями. Поскольку ограничение слишком длинного пути, по сути, заключается в том, что не может быть слишком глубокой иерархии каталогов, и теперь они являются ссылками на каталоги в разных местах, а не на один и тот же каталог, поэтому ограничения по длине нет.
Верно, через эту идею реализован pnpm.
Снова удалите node_modules , затем переустановите его с помощью pnpm и выполните pnpm install.
Вы обнаружите, что он печатает это предложение:
Пакеты жестко связаны из глобального хранилища в виртуальное хранилище , где виртуальным хранилищем является node_modules/.pnpm .
Давайте откроем node_modules и посмотрим:
Это действительно больше не плоско.Если полагаться на экспресс, то есть только экспресс в node_modules, и нет никакой призрачной зависимости.
Разверните .pnpm, чтобы увидеть:
Здесь проложены все зависимости, и все они жестко связаны с глобальным хранилищем, а затем через мягкие ссылки организованы зависимости между пакетами и пакетами. выражается в .pnpm/node_modules , это программные ссылки.
Другими словами, все зависимости жестко связаны из глобального хранилища с .pnpm/node_modules , а затем зависят друг от друга через программные ссылки.
Чиновник дал принципиальную схему, и вы можете понять ее, взглянув на нее: официальный адрес pnpm
Вот как работает pnpm .
Итак, оглядываясь назад, почему pnpm превосходен?
Прежде всего, самое большое преимущество - это экономия места на диске.Глобально сохраняется только одна копия пакета, а остальные - это мягкие и жесткие соединения.Сколько места на диске будет сэкономлено.
Второй быстрый , потому что он, естественно, будет быстрым за счет ссылки вместо копирования .
5. Лучшая практичность
Сказав так много, я думаю, вы найдете это pnpm довольно сложным. Много ли стоит его использование?
Наоборот, pnpm очень прост в использовании, и если у вас уже есть опыт работы с npm/yarn, вы даже можете легко перейти на pnpm.
В том, что все? Ниже более важным является поддержка методов управления проектами.
Личное ощущение: pnpm может лучше поддерживать переход от проекта Multirepo к проекту Monorepo по следующим причинам:
Если A зависит от X, B зависит от X и существует C, который не зависит от X, но использует X в своем коде. Из-за наличия продвижения зависимостей npm/yarn поместит X в node_modules корневого каталога, чтобы C мог работать локально, потому что в соответствии с механизмом загрузки пакетов узла он может быть загружен в node_modules проекта монорепозитория. корневой каталог X. Но только представьте, как только C упакован отдельно и пользователь устанавливает C отдельно, тогда X не будет найден, и об ошибке будет сообщено непосредственно при выполнении кода, который ссылается на X.
Подведем итог
Конечно, сегодня только углубленное изучение. Метод управления пакетами больше подходит для всех. Это зависит от наших собственных проектов. Это может варьироваться от человека к человеку, от проекта к проекту и от бизнеса к бизнесу ~~~
Приглашаем всех обсудить и учиться вместе~~~