nodejs peer dependencies — Что это такое (в том числе в npm)
Когда ты должен опираться на то, что у человека есть. Или этот пакет для тебя необязателен.
Пример: jquery-плагин, который подтягивается с бэкэнда (например через тег script) должен быть в одном экземпляре в системе, а значит он — «пэр» (peer), т.е. «равный» тому, кто от него зависит, его нельзя просто указать как одну из зависимостей чисто для данного пакета, ведь все кто от него зависят должна использовать одну версию.
Как происходит разрешение peer depencies
Одной из лучших особенностей pnpm является то, что в одном проекте конкретная версия пакета всегда будет иметь один набор зависимостей. Однако есть одно исключение из этого правила — пакеты с peer dependencies.
Peer-зависимости разрешаются из зависимостей, установленных выше в графе зависимостей, пока их версии совпадают с версиями родительских пакетов. Это означает, что если у foo@1.0.0 есть две peer-зависимости ( bar@^1 и baz@^1 ), то у него может быть разный набор зависимостей в одном проекте.
- foo-parent-1 - bar@1.0.0 - baz@1.0.0 - foo@1.0.0 - foo-parent-2 - bar@1.0.0 - baz@1.1.0 - foo@1.0.0 В приведенном выше примере foo@1.0.0 устанавливается для foo-parent-1 и foo-parent-2 . Both packages have bar and baz as well, but they depend on different versions of baz . В результате foo@1.0.0 имеет два разных набора из зависимостей: один с baz@1.0.0 , а другой с baz@1.1.0 . Чтобы это продолжало нормально работать, pnpm создаёт жёсткие ссылки на пакет foo@1.0.0 столько раз, сколько он попадается в разных наборах зависимостей.
Обычно, если пакет не имеет peer dependencies, он связан жёсткой ссылкой с папкой node_modules рядом с символическими ссылками на его зависимости, например:
node_modules └── .pnpm ├── foo@1.0.0 │ └── node_modules │ ├── foo │ ├── qux -> ../../qux@1.0.0/node_modules/qux │ └── plugh -> ../../plugh@1.0.0/node_modules/plugh ├── qux@1.0.0 ├── plugh@1.0.0 Однако, если пакет foo содержит peer dependencies, для него может быть несколько наборов зависимостей, поэтому мы создаем разные наборы зависимостей для отличающихся peer dependencies:
node_modules └── .pnpm ├── foo@1.0.0_bar@1.0.0+baz@1.0.0 │ └── node_modules │ ├── foo │ ├── bar -> ../../bar@1.0.0/node_modules/bar │ ├── baz -> ../../baz@1.0.0/node_modules/baz │ ├── qux -> ../../qux@1.0.0/node_modules/qux │ └── plugh -> ../../plugh@1.0.0/node_modules/plugh ├── foo@1.0.0_bar@1.0.0+baz@1.1.0 │ └── node_modules │ ├── foo │ ├── bar -> ../../bar@1.0.0/node_modules/bar │ ├── baz -> ../../baz@1.1.0/node_modules/baz │ ├── qux -> ../../qux@1.0.0/node_modules/qux │ └── plugh -> ../../plugh@1.0.0/node_modules/plugh ├── bar@1.0.0 ├── baz@1.0.0 ├── baz@1.1.0 ├── qux@1.0.0 ├── plugh@1.0.0 Мы создаем символические ссылки либо на foo внутри foo@1.0.0_bar@1.0.0+baz@1.0.0 , либо на foo@1.0.0_bar@1.0.0+baz@1.1.0 . Как следствие, загрузчик модулей в Node.js найдет правильные peer dependencies.
If a package has no peer dependencies but has dependencies with peers that are resolved higher in the graph, then that transitive package can appear in the project with different sets of dependencies. For instance, there’s package a@1.0.0 with a single dependency b@1.0.0 . b@1.0.0 has a peer dependency c@^1 . a@1.0.0 will never resolve the peers of b@1.0.0 , so it becomes dependent from the peers of b@1.0.0 as well.
Here’s how that structure will look in node_modules . In this example, a@1.0.0 will need to appear twice in the project’s node_modules — resolved once with c@1.0.0 and again with c@1.1.0 .
node_modules └── .pnpm ├── a@1.0.0_c@1.0.0 │ └── node_modules │ ├── a │ └── b -> ../../b@1.0.0_c@1.0.0/node_modules/b ├── a@1.0.0_c@1.1.0 │ └── node_modules │ ├── a │ └── b -> ../../b@1.0.0_c@1.1.0/node_modules/b ├── b@1.0.0_c@1.0.0 │ └── node_modules │ ├── b │ └── c -> ../../c@1.0.0/node_modules/c ├── b@1.0.0_c@1.1.0 │ └── node_modules │ ├── b │ └── c -> ../../c@1.1.0/node_modules/c ├── c@1.0.0 ├── c@1.1.0 NPM dependencies. В какую категорию импортировать пакет?
Перед тем как импортировать зависимость в свой проект, не забудьте спросить себя «А она точно мне нужна?». Может быть вам нужна какая-то малая ее часть, которую вы сможете написать самостоятельно. Но выбор между собственной имплементацией и сторонней — это уже отдельная тема.
Top comments (0)
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Cho thuê nhà giá rẻ, thuê nhà nguyên căn uy tín
Chothuenha — Jan 8
Secure Your Spring Boot and Angular Application with JWT Authentication: A Comprehensive Guide
Anbumani — Jan 8
Build a 3D Earth Globe Model in Three.js (PS: It’s easier than you think) ����
Arjun Vijay Prakash — Jan 8
Why most people fail to become a dev
⌨️ 9 лет в IT ���� 5 лет в online-образовании �� помогаю осваивать web-разработку �� создаю audio.com ⌚️ продуктивный лентяй ��♀️ муж и папа �� на Кипре
Как работает peerDependencies в package.json?
Можете, пожалуйста, на пальцах объяснить как и для чего использовать peerDependencies на проекте? Что туда писать? Я пытаюсь понять, но погуглив ясности мне это не добавило. Правильно ли я понимаю, что туда нужно записывать те зависимости, которые могут переплетаться в разных коммандах, для того чтобы при сборке вебпаком, он их не продублировал в бандле? Как вообще это работает?
- Вопрос задан более трёх лет назад
- 16473 просмотра
Комментировать
Решения вопроса 1
Wondermarin @Wondermarin
Не очень понял, где вы это нашли, но в Google можно найти ответ менее чем за 10 секунд.
peerDependencies — это особый тип зависимости, который может возникнуть только в том случае, если вы публикуете свой собственный пакет.
Наличие peerDependencies означает, что вашему пакету нужна такая же зависимость, как и человеку, устанавливающему ваш пакет. Используется для таких пакетов, как react, которые должны иметь единственную копию react-dom, которая также используется человеком, устанавливающим его.
Ответ написан более трёх лет назад
Нравится 2 2 комментария
sutaaliya @sutaaliya Автор вопроса
Вот это как раз и непонятно. Используется для таких пакетов, как react, которые должны иметь единственную копию react-dom, которая также используется человеком, устанавливающим его. Как у вас это в реальном проекте используется?
Wondermarin @Wondermarin
sutaaliya, у вас же в первом предложении написано условие:
. может возникнуть только в том случае, если вы публикуете свой собственный пакет.
Вы не используете peerDependencies в проекте, который не собираетесь публиковать.
Если вы публикуете свой проект, то он необязательно должен содержать peerDependencies, а содержит его только в том случае, если пакеты, использующиеся у вас и у пользователя должны быть в 1 экземпляре.
И установка таких пакетов выглядит следующим образом.
Без peerDependencies:
npm i my-awesome-package
С peerDependencies:
npm i my-awesome-package react-dom
React DOM в данном случае находится в peerDependencies my-awesome-package .