pnpmсовременныйНовые (больше вопросов)Инструмент управления пакетами, студенты, которые использовали его, будут привлечены его чрезвычайно быстрой скоростью установки и очень небольшим объемом дискового пространства!

Во-первых, почему он появляетсяpnpm? Автор изначальноyarnРелиз возлагал большие надежды, но после релиза некоторые ожидания автора не оправдались, но пусть автор немного разочаровался.

After a few days, I realized that Yarn is just a small improvement over npm. Although it makes installations faster and it has some nice new features, it uses the same flat node_modules structure that npm does (since version 3). And flattened dependency trees come with a bunch of issues
Через несколько дней я понял, что Yarn — это всего лишь небольшое улучшение по сравнению с npm. Хотя он ускоряет установку и имеет несколько приятных новых функций, он использует ту же плоскость, что и npm.node_modulesСтруктура (начиная с версии 3).扁平化的依赖树带来了一系列问题(Подробности будут обсуждены позже)

Почему это называетсяpnpm? Потому чтоpnpmКомментарии автора к существующим инструментам управления пакетами, особенноnpmиyarnСпектакль особенно разочаровал, поэтому название называетсяperfomance npm,Сейчасpnpm(высокопроизводительный npm)

как выделитьpnpmпреимущество в производительности? существуетpnpmНа официальном сайте представлена ​​таблица бенчмарков, которая сравниваетпроектВ npm, pnpm, yarn (обычная и PnP версии),install,updateВремя, проведенное в сценарии:

В следующей таблице показаны конкретные данные на рисунке выше:

action	cache	lockfile	node_modules	npm	pnpm	Yarn	Yarn PnP
install				1m 12.2s	15.7s	22.1s	27.5s
install	✔	✔	✔	1.6s	1.3s	2.6s	n/a
install	✔	✔		9.5s	4s	8.6s	1.9s
install	✔			14.2s	7.9s	14.2s	7.4s
install		✔		25.4s	13s	15.3s	21.1s
install	✔		✔	2.1s	1.8s	8.3s	n/a
install		✔	✔	1.6s	1.4s	9.4s	n/a
install			✔	2.1s	5.9s	15s	n/a
update	n/a	n/a	n/a	1.6s	12.1s	18.7s	32.4s

можно увидетьpnpm（橘色）В нашей проектной практике наблюдается значительное улучшение производительности (на основеgitlib)продвигатьболее очевидный(cache-pathsиstore dirпосле совместного использования)

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

метод установки node_modules

В настоящее время существует два метода установки: «Вложенная установка», «Плоская установка».

Вложенная установка

существуетnpm@3До,node_modulesструктура干净,可预测, потому что в node_modulesна зависимостьиметь свои собственныеnode_modulesпапка, впакет.jsonВсе зависимости указаны. Например, как показано ниже, проект зависит отfoo,fooположился наbar, зависимости показаны на следующем рисунке:

node_modules
└─ foo
   ├─ index.js
   ├─ package.json
   └─ node_modules
      └─ bar
         ├─ index.js
         └─ package.json

В приведенной выше структуре есть две серьезные проблемы:

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

Плоская установка

Чтобы решить вышеуказанные проблемы, npm пересмотрелnode_modulesструктуру и предложил плоскую структуру. существуетnpm@3+иyarnсередина,node_modulesСтруктура становится следующей:

node_modules
├─ foo
|  ├─ index.js
|  └─ package.json
└─ bar
   ├─ index.js
   └─ package.json

можно увидеть,hoistпод механизм,barбыл поднят на вершину. Как выглядит структура node_modules, если в проекте используются несколько версий одного и того же пакета?

Например: проектAppнапрямую зависит отA（version: 1.0）иC（version: 1.0）,AиCзависит от разных версийB,вAполагатьсяB 1.0,CполагатьсяB 2.0, это хорошо видно из рисунка нижеnpm2иnpm3+Структурные отличия:

СумкаB 1.0был повышен до верхнего уровня, здесь следует отметить, что несколько версий пакета只能有一个продвигается, и другие версии пакета будут установлены вложенными вв соответствующих зависимостях(похожийnpm2Структура).

Что касается того, какая версия пакета продвигается, то это зависит от порядка установки пакетов!

Изменения зависимостей, влияющие на повышениеномер версии, например, после изменения может бытьB 1.0, также возможноB 2.0продвигаться (но продвигаться может только одна версия)

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

Проблемы с npm3+ и пряжей

Фантомные зависимости

Phantom dependenciesназыватьсяпризрачная зависимостьилиФантомная зависимость, что очень просто объяснить, то есть пакет неpackage.jsonзависит, но пользователи могут ссылаться на этот пакет.

Причина этого явления обычно связана со структурой node_modules. Например, используя npm или yarn для установки зависимостей в проекте, в зависимостях есть зависимость, называемаяfoo,fooЭта зависимость также зависит отbar, yarn сделает сглаженную структуру для установленных node_modules и сгладит зависимости в node_modules, что эквивалентноfooиbarпоявляются ниже того же уровня. Затем, в соответствии с принципом поиска пути nodejs, пользователи могут потребоватьfoo, а также требуютbar.

Режим адресации nodejs :(узнать больше)

1. Для основного модуля => абсолютная адресация пути
2. стандартная библиотека узла => относительная адресация пути
3. Сторонние библиотеки (установленные через npm) в библиотеки под node_modules:

3.1 Сначала найдите node_modules/xxx в текущем пути
3.2 Рекурсивно идите снизу вверх к пути верхнего уровня, ища ../node_modules/xxx
3.3 Второй шаг цикла
3.4 Найдите .node_modules/xxx в глобальном пути к среде

двойники нпм двойники нпм

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

Например: проект имеетpackageA,packageB,packageC,packageD.packageAзависит от пакетаX 1.0и пакетY 1.0,packageBзависит от пакетаX 2.0и пакетY 2.0,packageCзависит от пакетаX 1.0и пакетY 2.0,packageDзависит от пакетаX 2.0и пакетY 1.0.

существуетnpm2, структура следующая

- package A
    - packageX 1.0
    - packageY 1.0
- package B
    - packageX 2.0
    - packageY 2.0
- package C
    - packageX 1.0
    - packageY 2.0
- package D
    - packageX 2.0
    - packageY 1.0

существуетnpm3+иyarn, из-за наличия подъемного механизма была обновлена ​​одна версия каждого из X и Y, а структура каталогов выглядит следующим образом.

- package X => 1.0版本
- package Y => 1.0版本

- package A
- package B
    - packageX 2.0
    - packageY 2.0
- package C
    - packageY 2.0
- package D
    - packageX 2.0

Как показано выше, пакеты packageX 2.0 и packageY 2.0 многократно устанавливаются многократно, что приводит к некоторой потере производительности npm и производительности пряжи.

Этот сценарий особенно очевиден в сценарии с несколькими пакетами монорепозиториев, который такжеyarn workspaceДело в том, что часто жалуются, и реализация алгоритма выравнивания тоже достаточно сложна, а стоимость модификации высока. ТакpnpmКак решить эту проблему?

Способ взлома pnpm: сетка + тайловая структура node_modules

Некоторые базовые знания:Основные понятия индексного дескриптора, жесткой ссылки и символической ссылки

pnpmпользователей могут найти егоnode_modulesЭто не плоская структура, а структура дерева каталогов, похожая наnpm version 2.xСтруктура в версии, как показано на следующем рисунке

Также есть.pnpmкаталог, как показано ниже

.pnpmВсе пакеты хранятся в плитках, а обычные пакеты можно найти в папках с этим шаблоном именования (peerDepисключение):

.pnpm/<organization-name>+<package-name>@<version>/node_modules/<name>

// 组织名(若无会省略)+包名@版本号/node_modules/名称(项目名称)

мы называем.pnmpкаталог виртуального хранилища, который передается через<package-name>@<version>Для достижения изоляции и повторного использования между разными версиями одного и того же модуля, поскольку он будет генерироваться только на основе зависимостей в проекте, продвижения не будет, поэтому он не будет существовать, как упоминалось ранее.Phantom dependenciesпроблема!

Итак, как это связано с файловыми ресурсами? Как это можно использовать в проекте?

ответStore + Links!

Store

pnpmМесто хранения ресурса на диске.

pnpmИспользуйте файл с именем .pnpm-storestore dir, по умолчанию в Mac/linux будет установлено значение{home dir}>/.pnpm-store/v3; в Windows он будет установлен в корневой каталог текущего диска, например C (C/.pnpm-store/v3), диск D (D/.pnpm-store/v3).

Для получения подробной информации см.@pnpm/store-path этоpnpmКод в подпакете:

const homedir = os.homedir()
if (await canLinkToSubdir(tempFile, homedir)) {
  await fs.unlink(tempFile)
  // If the project is on the drive on which the OS home directory
  // then the store is placed in the home directory
  return path.join(homedir, relStore, STORE_VERSION)
}

Так как каждый диск имеет свой способ хранения, Магазин будет разделен в соответствии с диском. Если домашний каталог существует на диске, хранилище будет создано в<home dir>/.pnpm-store; если на диске нет домашнего каталога, хранилище будет создано в корне файловой системы. Например, если установка происходит при включенном монтировании/mntв файловой системе , то хранилище будет в/mnt/.pnpm-storeсоздано в . То же самое верно и для систем Windows.

Одно и то же хранилище можно настроить на разных дисках, но в этом случаеpnpmбудетСкопируйте пакетвместожесткая ссылкаони, потому чтоЖесткие ссылки могут встречаться только в одном и том же разделе в одной и той же файловой системе..

магазин окон, как показано ниже

pnpm installВ процессе установки мы увидим следующую информацию, в этомContent-addressable storeэто то, о чем мы говоримStore

Хранилище с адресацией по содержимому CAS, — это способ хранения информации, который извлекает информацию на основе содержимого, а не местоположения.

Виртуальный магазин Виртуальный магазин, каталог, указывающий на сохраненные ссылки, все прямые и косвенные зависимостиСсылка на сайтВ этот каталог каталог .pnpm в проекте

Если это npm или yarn, то эта зависимость используется в нескольких проектах и ​​будет перезагружаться каждый раз при установке.

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

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

Ответ, конечно, будет, для этой проблемы pnpm предоставляет команду для решения этой проблемы:pnpm store | pnpm.

В то же время эта команда предоставляет опцию, метод использованияpnpm store prune, который предоставляет функцию для удаления некоторых пакетов, на которые не ссылается глобальный проект, например, пакетаaxios@1.0.0ссылается проект, но модификация приводит к обновлению пакета в проекте до1.0.1, то аксиома 1.0.0 в хранилище становится пакетом без ссылок, выполняемpnpm store pruneВы можете удалить его в магазине.

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

Увидев это, вы должны иметь некоторое представление о Store, а затем давайте посмотрим, как файлы в проекте связаны с Store.

Ссылки (жесткая ссылка и символическая ссылка)

Я до сих пор помню, что в начале статьи я поставил две диаграммы пляжных меток, и вы можете увидеть очевидное улучшение производительности на диаграмме (если вы использовали ее, ощущения будут более очевидными)!

Как pnpm добился такого большого улучшения? Частично причина заключается в использованииHard link, что уменьшает количество загрузок файлов, тем самым улучшая загрузку и скорость отклика.

hard link

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

pnpmБудет вStore(Магазин выше) хранить элементы в каталогеnode_modulesфайлhard links, прямой доступ к файловым ресурсам по этим ссылкам.

Например, например, в проекте есть зависимость 2MBreact, в pnpm это выглядит такreactЗависимости занимают 2 МБ каталога node_modules и 2 МБ глобального каталога хранилища одновременно (4 МБ вместе), но посколькуhard linkМеханизм позволяет получить доступ к одному и тому же пространству 2 МБ в двух каталогах из двух разных мест.CAS寻址напрямую ссылается на файл, поэтому на самом деле этоreactЗависимости занимают только 2 МБ места, а не 4 МБ.

Из-за такого механизма каждый раз при установке зависимости, если это одна и та же зависимость, и многие проекты используют эту зависимость, то эта зависимость на самом деле в лучшем случае (то есть одна и та же версия) нужно установить только один раз.

пока вnpmиyarnВ , если зависимость используется несколькими проектами, произойдет несколько загрузок и установок!

В случае с npm или yarn эта зависимость используется в нескольких проектах и ​​будет повторно загружаться при каждой установке.

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

пройти черезStore + hard linkкстати, не только решает проблемы в проектеNPM doppelgangersПроблема не существует между проектами, поэтому она решается отличноnpm3+иyarnПроблема с дублированием пакетов!

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

В ответ на это явление pnpm предоставляет команду для решения этой проблемы:pnpm store | pnpm.

В то же время эта команда предоставляет опцию, метод использованияpnpm store prune, который предоставляет функцию для удаления некоторых пакетов, на которые не ссылается глобальный проект, например, пакетаaxios@1.0.0ссылается проект, но модификация приводит к обновлению пакета в проекте до1.0.1, то аксиома 1.0.0 в хранилище становится пакетом без ссылок, выполняемpnpm store pruneВы можете удалить его в магазине.

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

symbolic link

так какhark linkМожет использоваться только для файлов, а не для каталогов, ноpnpmизnode_modulesЭто древовидная структура каталогов, так как же ссылаться на файлы? пройти черезsymbolic link(также известная как мягкая цепочка или символическая ссылка) для достижения!

Из предыдущего объяснения мы знаемpnpmпроходить глобальноStoreдля хранения всех зависимостей node_modules, а в.pnpm/node_modulesхранить жесткие ссылки проекта вhard linkЧтобы связать реальные файловые ресурсы, в проекте черезsymbolic linkСсылка на.pnpm/node_modulesВ каталогах зависимости размещаются на одном уровне, чтобы избежать циклических мягких цепочек.

pnpmиз node_modulesНа первый взгляд структура выглядит странно:

1. Он полностью совместим с Node.js.
2. Пакеты и их зависимости прекрасно организованы.

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

Предположим, у нас есть монорепозиторий, в котором естьrepo A,repo B,repo Cиrepo D4 репо. Каждое репо имеет свой собственный набор зависимостей (включаяdependenciesиpeerDependencies),предполагаемыйСтруктура показана на рисунке ниже: (обратите внимание, что есть одноранговая деп)

Нижеpnpm workspaceСредний, относительно понятный (если неясный, оставьте сообщение, я могу его изменить!) ОбъяснениеStoreиLinksОтношения между:

Официальный сайт также обновил аналогичную схему звонков, вы тоже можете взглянуть!

PeerDependencies

Одной из лучших особенностей pnpm является то, что внутри проекта конкретная версия «пакета» всегда будет иметь только один набор зависимостей. Есть одно исключение из этого правила — пакет с [одноранговыми зависимостями] (https://docs.npmjs.com/files/package.json#peerdependencies).

Обычно, еслиpackageБез одноранговых зависимостей он жестко связан рядом с символическими ссылками своих зависимостей.node_modules,нравится:

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

pnpmСоздайте foo@1.0.0_bar@1.0.0+baz@1.0.0 илиfoo@1.0.0_bar@1.0.0+baz@1.1.0внутриfooмягкая ссылка. Поэтому распознаватель модулей Node.js найдет правильные одноранговые узлы.

peerDepПравила именования пакетов следующие (выглядит очень хлопотно)

.pnpm/<organization-name>+<package-name>@<version>_<organization-name>+<package-name>@<version>/node_modules/<name>

// peerDep组织名(若无会省略)+包名@版本号_组织名(若无会省略)+包名@版本号/node_modules/名称(项目名称)

еслиpackageНет одноранговых зависимостей, но его зависимости имеют одноранговые зависимости, которые разрешаются в более высоком графе зависимостей., то этот переносpackageВ вашем проекте может быть несколько разных наборов зависимостей. Например,a@1.0.0имеет единственную зависимостьb@1.0.0. b@1.0.0Существует сверстник, который зависит отc@^1. a@1.0.0никогда не анализироватьb@1.0.0сверстников, так что это также будет зависеть отb@1.0.0ровесник.

Если вам нужно решить проблему с несколькими экземплярами, представленную peerDep, вы можете передать.pnpmfile.cjsФайл изменяет зависимости зависимостей.

Функциональные различия между pnpm и npm и пряжей

Следующая таблица взята с официального сайта, и заинтересованные студенты могут обратиться к ней самостоятельно.

Функции	pnpm	Yarn	npm
Поддержка рабочей области (monorepo)	✔️	✔️	✔️
Изолированныйnode_modules	✔️ - по умолчанию	✔️	✔️
приподнятыйnode_modules	✔️	✔️	✔️ - по умолчанию
Plug'n'Play	✔️	✔️ - по умолчанию	❌
Нулевая установка	❌	✔️	❌
Исправление зависимостей	❌	✔️	❌
管理 Node.js 版本(эксклюзивно для pnpm)	✔️	❌	❌
заблокировать файл	✔️ -pnpm-lock.yaml	✔️ -yarn.lock	✔️ -package-lock.json
Покрытие поддержки	✔️	✔️ - по разрешениям	✔️
内容可寻址存储(CAS)(эксклюзивно для pnpm)	✔️	❌	❌
динамическое выполнение пакета	✔️ - отpnpm dlx	✔️ - отyarn dlx	✔️ - отnpx

Из диаграммы видно, что их два.pnpmУникальная реализация:管理 Node.js 版本и内容可寻址存储(CAS)

Среди них CAS был введен ранее, давайте поговорим о нем管理 Node.js 版本.

это в.npmrcфайл, используемый в настройках модуля Nodeuse-node-versionнастроить (Другая информация о конфигурации)

use-node-versionИспользуется для указания точной версии Node.js для применения к среде выполнения проекта, поддерживаетsemverнастройки версии. После установки pnpm автоматически установит указанную версию Node.js и будет использовать ее для выполнения.pnpm runкоманда илиpnpm node Заказ.

// 指定版本16.x
use-node-version=^16.x

Текущая установка 14.x.После использования вышеуказанной конфигурации будет предупреждение при выполнении: WARN  Unsupported engine: wanted: {"node":">=14.0.0"} (current: {"node":"^16.x","pnpm":"6.22.2"})но не влияет на результат выполнения

workspace

pnpmиnpm,yarnТочно так же есть встроенная поддержка монорепозитория, который относительно прост в использовании.Создайте новый в корневом каталоге проекта.pnpm-workspace.yamlфайл и просто объявите соответствующее рабочее пространство.

packages:
  # 所有在 packages/ 子目录下的 package
  - 'packages/**'

протокол рабочей области рабочей области

По умолчанию, если доступноpackagesсоответствует объявленным доступным областям, pnpm свяжет их из рабочей областиpackages. Например, еслиbarЕсть"foo"："^1.0.0"Эта зависимость , тоfoo@1.0.0 Ссылка на bar. но если barзависимости имеют"foo": "2.0.0" ,иfoo@2.0.0не существует в рабочей области, он будет установлен из реестра npmfoo@2.0.0. Такое поведение вносит некоторую неопределенность.

К счастью,pnpmиз версии3.7Начать поддержку протокола Workspaceworkspace:. При использовании этого протокола pnpm откажется разрешать что-либо кроме локальной рабочей области.packageЧто угодно, кроме . Итак, если вы установите"foo": "workspace:2.0.0", установка завершится ошибкой, потому что"foo@2.0.0"Не существует в рабочей области. Эта функция особенно полезна в монорепозиториях.

Путем изменения конфигурацииlink-workspace-packagesчтобы изменить способ использования пакета (удаленная загрузка или локальная).

link-workspace-packagesимеет три значения

• trueПо умолчанию используются локально доступные пакеты;
• falseПосле отключения он будет загружен и установлен локально из реестра и использован (аналогично установке yarn\npm)
• deepДоступно начиная с v5, зависимости в локальных пакетах (подпакетах) также могут быть связаны и использованы.

Он поддерживает два метода ссылки:Ссылка на псевдонимиотносительная ссылка.

Ссылка на псевдоним

Если в рабочей области есть файл с именемlocal-packageпакет, на который можно ссылаться"local-package": "workspace:". Если это другой псевдоним, вы можете ссылаться на него следующим образом: "ref-package": "workspace:local-package@*"

относительная ссылка

Если пакеты имеют одинаковый уровеньrepoA,repoB,вrepoAзависит отrepoB, ты можешь написать"repoA": "workspace:../repoB".

Перед публикацией обе эти ссылки будут заменены спецификацией обычной версии.

фильтр фильтр

Этот параметр позволяет нам применить команду к указанному пакету, аналогичноjQueryиDomселектор, записанный следующим образом

pnpm <command> --filter <package_selector>

В то же время он также поддерживает цепные вызовы, вы можете писать несколько вызовов одновременно, как показано ниже,

pnpm <command> --filter selector1 --filter selector2 -- filter=!selector3

Селекторы также поддерживаются в Lerna, параметрыscope, в следующей статье сравниваетсяLernaиpnpmСелектор, заинтересованные студенты могут посмотреть
Селекторы Lerna и pnpm

соответствие

Правила сопоставления поддерживают три измерения сопоставления:packageName（包名）,dirName （目录名）,git commit/branch（git提交或分支名）

packageName（包名）Поддерживает сопоставление имен пакетов с подстановочными знаками, сопоставление пакетов и зависимостей (прямых и косвенных зависимостей), сопоставление зависимостей (прямых и косвенных зависимостей), сопоставление пакетов по зависимостям (прямых и косвенных зависимостей) и сопоставление зависимостей (прямых и косвенных зависимостей).

// 包名通配符匹配，其中scope是可选的，当单个scope时：`--filter=core` 将选择 `@babel/core`;多scope不生效
pnpm test --filter "@babel/core"\
pnpm test --filter "@babel/*"\
pnpm test --filter "*core"

// 包和依赖项(直接和间接依赖)匹配，要选择一个软件包及其依赖项 (直接和非直接) 在包名称后加上省略号： `<package_name>...`
pnpm test --filter foo...
pnpm test --filter "@babel/preset-*..." // 可选择一组根目录包

// 依赖项(直接和间接依赖)匹配，要选择一个软件包及其依赖项 (直接和非直接)， 在包名前添加一个山形符号加上上面提到的省略号
pnpm test --filter foo^...
pnpm test --filter "@babel/preset-*^..." // 可选择一组根目录包

// 包被依赖项(直接和间接依赖)匹配，在包名前添加一个省略号: `...<package_name>`。
pnpm test --filter ...foo // 将运行 `foo` 以及依赖于它的所有包的测试：

// 被依赖项(直接和间接依赖)匹配
pnpm test --filter "...^foo" // 将运行所有依赖于 `foo` 的包的测试

Внимательные друзья могли обнаружить, что ядром является:элементpackageName+ две операции (...и^) расположение

• packageNameимя, подстановочные знаки поддерживаются
• ...Выберите пакет и его зависимости, которые необходимо разместить до или после имени пакета.
  • ...packageName одеялоСовпадение зависимостей
  • packageName...Совпадение зависимостей
• ^Исключает текущий пакет, может использоваться отдельно, но рекомендуется и...(зависимость) использовать с

packageName, ...packageName, packageName..., ...packageName..., ...^packageName, packageName^..., ...^packageName^..., ...^packageName... ,... имя_пакета^...

Будет намного яснее, если вы посмотрите на это таким образом.

dirName （目录名）Поддерживает ссылки на относительные пути (обычно в формате POSIX), форму указанных элементов каталога (может использоваться с операциями)

// 相对路径引用
pnpm <cmd> --filter ./packages

// 搭配操作符（`...`和`^`）
pnpm <cmd> --filter ...{<directory>}
pnpm <cmd> --filter {<directory>}...
pnpm <cmd> --filter ...{<directory>}...

git commit/branch（git提交或分支名）, это иpackageNameИспользование похоже, но его можно использовать в сочетании с двумя предыдущими.

// 运行自 `master` 以来所有变动过的包以及被其依赖的包的测试
pnpm test --filter "...[origin/master]"

// 和`package-name`搭配使用
pnpm <cmd> --filter "...@babel/*{components}[origin/master]"

// 和`dir-name`搭配使用
pnpm <cmd> --filter "...{packages}[origin/master]..."

исключать

Просто добавьте!, селектор правил фильтрации становится элементом исключения.

существуетgitbash,zshВ других оболочках "!" следует экранировать: \!, В противном случае будет сообщеноbash: !{packageName}: event not foundОшибка

смесь кратности

так какfilterПоддерживаются связанные вызовы, поэтому два сценария можно смешивать. Например: организация@fe, в нем есть пакеты A, B, C, D, нам нужно выбрать другие пакеты, которые не содержат пакет B для выполнения команды сборки, которую можно написать так

pnpm build --filter @fe/* --filter=!@fe/B

В случае смешивания (Фильтр1, Фильтр2,...,ФильтрN) сначала вступит в силу Фильтр1, а затем Фильтр2, пока N, а затемECMAScriptПодобное, конечно, может быть сложнее в реальном бизнесе, и его нужно анализировать по сценарию.

командная команда

Обратитесь к официальному веб-сайту, классифицируйте в соответствии со сценариями использования и перечислитечастьИспользование команды, все команды, пожалуйста, перейдите кОфициальный сайтПроверять

управлять зависимостями

pnpm add

addКоманда - старый друг, сyarn addТочно так же устанавливайте пакеты и зависимые пакеты, по умолчанию устанавливается вdependenciesсередина. Обратите внимание, что в рабочей области, если вы хотите установить в корневую рабочую область, вам нужно добавить-wили--ignore-workspace-root-check, вам нужно использовать--filter, иначе установка завершится ошибкой

5 положений установки:

• npm(по умолчанию): в рабочей области сначала подтверждается ссылка на измененный пакет.Если это так, он будет установлен в соответствии с используемой версией; в нерабочей области по умолчанию будет изnpm registryУстановите последний пакет. Например:pnpm add express@nightly(тег),pnpm add express@1.0.0(версия),pnpm add express@2 react@">=0.1.0 <0.2.0"(семантическое версионирование).
• workspace: Когда рабочая область устанавливает зависимости, она будет установлена ​​из настроенного источника, в зависимости от того, установлен ли онlink-workspace-packages, и будет ли использованиеworkspace: range protocol.
• local file system: Локальная установка Существует два метода установки: исходные файлы и локальные каталоги.
• reomote tarball: Удаленная установка должна включать доступныйURL.
• git repository:git install Установить от автора git через git clone.

Общие параметры параметров

• --save-prod, -P: установить вdependencies
• --save-dev, -D: установить вdevDependencies
• --save-optional, -O: установить вoptionalDependencies
• --save-peer: установить вpeerDependenciesиdevDependenciesсередина
• --global: установить глобальные зависимости.
• --workspace: добавлять только зависимости, найденные в рабочей области.

pnpm remove

Псевдоним:rm, uninstall, un

от node_modulesи проектpackage.jsonУдалите пакет из . параметр, за которым следуетaddАналогично, не будем расширяться

pnpm install

Псевдоним:i

pnpm installИспользуется для установки всех зависимостей проекта. В среде CI, если есть файл блокировки, который необходимо обновить, установка завершится ошибкой, поэтому после каждого обновления версии его необходимо установить локально, а затем отправить, иначе выпуск версии завершится ошибкой.

Расскажите об этом здесь--fix-lockfileи--shamefully-hoist.

• --fix-lockfileПараметр автоматически восстанавливает поврежденную запись файла блокировки, что особенно полезно при его первой установке.Если вы столкнулись с пакетом, который не может быть найден, это может быть проблема фантомной зависимости.Вам необходимо вручную добавить зависимости или устранить причину .
• --shamefully-hoistсоздать квартируnode_modulesструктура каталогов, похожая наnpm или yarn. Этокрайне не рекомендуетсяДа, но это решает проблему неиспользуемой суммы после миграции в некоторых сценариях.

pnpm import

importКоманды поддерживают генерацию из файлов блокировки в других форматах.pnpm-lock.yamlфайл, в настоящее время поддерживает три формата исходных файлов

• package-lock.json
• npm-shrinkwrap.json
• yarn.lock(начиная с версии 6.14.0)

Я лично думаю, что эта командаlerna importЛучше использовать вместе,lerna importимпортировать историю коммитов git (выучить больше), ответственный за генерациюpnpm-lock.yamlфайл, который полностью восстанавливает историю коммитов проекта и зависимости версий.

pnpm prune

pruneУдаление ненужных зависимостей в проекте, поддержка элементов конфигурации--prod(удалено вdevDependenciesпакет, указанный в ) и--no-optional(удалено вoptionalDependenciesПакет, указанный в . ).

При использовании в глобальном или одиночном режимеstore-dirЭто особенно полезно при использовании сценария для периодического удаления зависимостей исторических версий.

ПРЕДУПРЕЖДЕНИЕ Команда prune в настоящее время не поддерживается вmonorepoвыполнять рекурсивно. Вы можете удалить тот, который устанавливает только производственные зависимостиmonorepoнемного node_modulesпапку, а затем повторно использоватьpnpm install --prod Установить.

просмотреть зависимости

pnpm list

Псевдоним:ls.

Эта команда выведет все установленные установки в виде древовидной структуры.packageверсия и ее зависимости. Добавить параметры--jsonЖурнал будет выводиться в формате JSON.

запускать скрипты запускать скрипты

pnpm run

Псевдоним:run-script.

управлятьpackageСкрипты, определенные в файле манифеста.

если у вас естьstartСкрипт настроен вpackage.json , нравится:

"scripts": {
    "start": "start-storybook -s ./assets -p 23762 -c __storybook"
}

Теперь вы можете использоватьpnpm run startЗапустите скрипт! Просто, верно? Еще одна вещь, на которую стоит обратить внимание тем, кто не любит печатать и тратить время впустую, это то, что все скрипты будут иметь псевдонимы для команды pnpm, поэтому в конечном итогеpnpm run startАббревиатура отpnpm start(относится только ксценарии, которые не имеют того же имени, что и существующая команда pnpm). Будьте осторожны, чтобы не вкладывать команды внутриpnpm run command, иначе это приведет к выполнению цикла.

Суммировать

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

• node_modulesС изменением конструкции есть два способа гнездовой установки и плоской установки, конечно, у них есть свои преимущества и недостатки.
• pnpmКак решить существующую проблему за счет не плоской установкиnode_modulesпроблемы
• Уникальный набор функций:管理 Node.js 版本и内容可寻址存储(CAS)
• Общие команды:install,add,remove,update,publishЖдать
• workspaceкак пользоваться
• filterНекоторые распространенные варианты использования селекторов фильтров:matchingсовпадение,excludingисключить иmultiplicityсмешивание

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

• Плоские node_modules — не единственный способ
• Hard links and Symbolic links
• Woohoo. KO произведено. IO/node будет /why-…
• Year Rank.GitHub.IO/how-year-rank-i let…
• узел будет .org/API/modules…