peer dependencies что это
Зависимости JavaScript: Все, что вы когда-либо хотели знать, но боялись спросить
Ваше подробное руководство по пяти типам зависимости
Также приглашаем всех желающих на открытый вебинар по теме «Vue 3 — возможности новой версии одного из самых популярных фронтенд фреймворков». На занятии участники вместе с экспертом:
— рассмотрят ключевые отличия в синтаксисе vue2 от vue3;
— разберут, как работать с vue-router и VueX в новой версии фреймворка;
— cоздадут проект на Vue 3 с нуля с помощью Vue-cli.
Независимо от того, являетесь ли Вы back-end разработчиком, работающим с Node.js, или front-end разработчиком, использующим Node.js только в качестве инструмента для пакетирования и комплектации, Вы наверняка наткнулись на систему зависимостей.
Но почему их 5 типов (да, это не опечатка, есть 5 типов зависимостей), и для какого случая они используются? На эти вопросы мы ответим сегодня, так что сядьте поудобнее и расслабьтесь, потому что это будет интересно.
Normal (runtime) dependencies (cтандартные (во время выполнения программы) зависимости)
Давайте начнем с простого, хорошо?
Однако, это еще не все. Вместо точного номера версии вашей зависимости вы можете указать:
Когда ты будешь использовать стандартные зависимости?
Стандартные зависимости будут содержать все, что требуется вашему проекту для работы, и что не может быть предоставлено другим модулем.
Это может показаться простым, но если, например, ваш проект на самом деле является модулем, то вам нужно более внимательно разобраться в том, что это значит. Если ваш модуль предназначен для использования с другими проектами, такими как React или Babel, ваши зависимости не должны включать их, так как они, как предполагается, уже присутствуют, тем не менее, они все равно нужны (мы это увидим позже, где они появятся через секунду).
Так что, помните, если это абсолютно необходимо для работы вашего проекта, и вы не можете рассчитывать на то, что другая библиотека включит их, то они должны быть включены в ваш список зависимостей.
Peer dependencies (Равные зависимости)
Peer dependencies — это особый вид зависимостей, в том смысле, что они предназначены для указания тех пакетов, которые требуются вашему проекту, или, вернее, с которыми он совместим. Тем не менее, вы можете не запрашивать их конкретно в своем коде.
Подождите, зависимость, которая вам не требуется? Я знаю, это звучит странно, но подумайте о плагине Babel, он нуждается в Babel в том смысле, что если его там нет, то он не сможет работать, однако, он может и не требовать Babel явно для чего-либо.
Теперь, потенциально, вы можете добавить Babel в список стандартных зависимостей, однако, при установке плагина, он также попытается установить Babel. И если вы используете, например, NPM, он установит его как локальную зависимость вашего плагина, что означает — он будет дублировать уже существующую установленную Babel для хост-проекта, находящегося в папке плагина.
Когда ты будешь использовать Peer dependencies?
Вы можете прочитать больше о Peer dependencies здесь, однако, поймите, что вы будете использовать их только тогда, когда нужно указать на недостаточно прочную связь с другим проектом.
Другими словами:
Когда она вам нужна, но нет необходимости употреблять ее сразу и однозначно. Тогда это peer dependency.
Когда она вам нужна, но она уже должна быть установлена другим проектом. Тогда это peer dependency.
Примерами того, когда вы хотите использовать peerDependencies, являются:
Babel плагины. Ты хочешь декларировать такие же вещи, как и сам Babel, в качестве равной зависимости (peer dependency).
Если вы собираете Micro Frontend (Микрофронтенд), пытаясь решить, какие зависимости являются внешними (чтобы они не были связаны), а какие нет. Peer dependencies могут быть хорошим решением для этого.
Bit components. Если вы создаете и публикуете front-end компоненты, например, когда вы совместно используете React-компоненты на Bit (Github), вам нужно назначить react библиотеку как peer dependency. Это позволит удостовериться, что нужная библиотека доступна в хостинговом проекте без установки ее в качестве прямой зависимости от него.
Например, взгляните на этот React компонент, который я опубликовал некоторое время назад: это простая кнопка, которую можно выбрать (вы нажимаете на нее и она остается выбранной до тех пор, пока не будет нажата снова).
Если вы установите его, вы получите полный код, который содержит файл package.json, в котором перечислены все peer dependencies:
Обратите внимание, что пакет не имеет прямой зависимости, несмотря на то, что для работы ему необходима React-библиотека.
Это также помогает сохранить размер нашего компонента как можно меньше (1KB) — ничего лишнего не добавляется.
Dev Dependencies (Dev зависимости)
Имя говорит обо всем, не так ли? Я имею в виду, что так и должно быть, но когда имена действительно помогают нам, разработчикам, в нашей повседневной работе? Я точно знаю.
Зависимости процесса разработки (Development dependencies) предназначены для того, чтобы содержать только те модули, которые вы используете на этапе разработки вашего проекта.
Да, но есть и другие, например, инструменты для подшивки (linting tools), документация и тому подобное.
Дело в том, что если вы можете запустить проект без использования этого набора инструментов, тогда это dev dependency.
Принцип их работы заключается в том, что зависимости разработки устанавливаются только при запуске npm install или npm link из корневой папки вашего проекта.
Подумайте об этом, в этом случае имеет смысл установить их, так как вы разрабатываете свой собственный проект. Но если вы устанавливаете свой проект внутри другого, то этот процесс будет игнорировать ваши dev dependencies.
Когда ты будешь использовать dev dependencies?
Любая зависимость, которая не требуется для производственного процесса, скорее всего, будет считаться dev dependencies (зависимости развития).
Дело в том, что это отлично работает для всех модулей, кроме вашего хост-проекта.
Все установленные внутри хост-проекта зависимости будут пропускать dev-зависимости модулей во время инсталляции, но всякий раз, когда вы повторно запускаете npm install в хост-проекте, он будет устанавливать заново все пропущенные ранее dev-зависимости модулей.
Поэтому рассмотрим использование Dev зависимостей только для пакетов и модулей, которые будут использоваться другими проектами.
Связанные зависимости (Bundled Dependencies)
Это очень удобно при распространении ваших пакетов в однофайловом формате (помните, что вы также можете указать их URL или локальный путь как стандартную зависимость).
Дополнительные зависимости (Optional dependencies)
Наконец, этот тип зависимостей такой же, как и обычные, они ведут себя и могут быть настроены точно таким же образом. Единственная разница? NPM не выйдет с ошибкой, в случае, если не сможет установить их.
Обычно, когда вы запускаете npm install и процесс не может установить обычную зависимость по какой-либо причине (будь то из-за сбоя в сети, не может найти файл, версию или что-нибудь ещё), то он выдаст ошибку и отменит процесс установки.
Дополнительные зависимости вместо этого позволят NPM продолжать работу. Конечно, вы отвечаете за написание кода, который способен справиться с этими отсутствующими зависимостями, например:
Когда вы будете использовать дополнительные зависимости (optional dependencies)?
Очевидный пример использования этого типа зависимостей — когда вы используете ненадежный источник. Я спрашиваю, зачем это делать? Хороший вопрос. Понятия не имею, но вы определенно можете это сделать, единственная проблема в том, что вам нужно убедиться, что ваш код может с этим справиться, если отсутствуют зависимости.
Но другой интересный вариант использования, это установка действительно необязательных зависимостей (optional dependencies). Я имею в виду, что иногда у вас могут быть специфические для системы зависимости, для таких вещей, как совместимость с CI(Continuous Integration)-платформой. В таких сценариях, когда используете платформу, вы захотите установить эти зависимости, в другом случае, проигнорируете.
Каждый, кто когда-либо пользовался NPM в тот или иной момент, слышал о стандартных и dev-зависимостях. Остальные 3, однако, можно считать менее популярными собратьями.
Хотя некоторые из них действительно сосредоточены на очень специфических сценариях, они могут быть очень удобны, когда с ними сталкиваешься.
Знали ли вы, что у вас так много вариантов? Оставьте комментарий ниже, если вы использовали некоторые из менее распространенных и расскажите нам, как вы их использовали!
Зависимости JavaScript: Все, что вы когда-либо хотели знать, но боялись спросить
Ваше подробное руководство по пяти типам зависимости
Привет, хабровчане. Для будущих учащихся на курсе «JavaScript Developer. Professional» подготовили перевод материала.
Также приглашаем всех желающих на открытый вебинар по теме «Vue 3 — возможности новой версии одного из самых популярных фронтенд фреймворков». На занятии участники вместе с экспертом:
— рассмотрят ключевые отличия в синтаксисе vue2 от vue3;
— разберут, как работать с vue-router и VueX в новой версии фреймворка;
— cоздадут проект на Vue 3 с нуля с помощью Vue-cli.
Независимо от того, являетесь ли Вы back-end разработчиком, работающим с Node.js, или front-end разработчиком, использующим Node.js только в качестве инструмента для пакетирования и комплектации, Вы наверняка наткнулись на систему зависимостей.
Но почему их 5 типов (да, это не опечатка, есть 5 типов зависимостей), и для какого случая они используются? На эти вопросы мы ответим сегодня, так что сядьте поудобнее и расслабьтесь, потому что это будет интересно.
Normal (runtime) dependencies (cтандартные (во время выполнения программы) зависимости)
Давайте начнем с простого, хорошо?
Однако, это еще не все. Вместо точного номера версии вашей зависимости вы можете указать:
Когда ты будешь использовать стандартные зависимости?
Стандартные зависимости будут содержать все, что требуется вашему проекту для работы, и что не может быть предоставлено другим модулем.
Это может показаться простым, но если, например, ваш проект на самом деле является модулем, то вам нужно более внимательно разобраться в том, что это значит. Если ваш модуль предназначен для использования с другими проектами, такими как React или Babel, ваши зависимости не должны включать их, так как они, как предполагается, уже присутствуют, тем не менее, они все равно нужны (мы это увидим позже, где они появятся через секунду).
Так что, помните, если это абсолютно необходимо для работы вашего проекта, и вы не можете рассчитывать на то, что другая библиотека включит их, то они должны быть включены в ваш список зависимостей.
Peer dependencies (Равные зависимости)
Peer dependencies — это особый вид зависимостей, в том смысле, что они предназначены для указания тех пакетов, которые требуются вашему проекту, или, вернее, с которыми он совместим. Тем не менее, вы можете не запрашивать их конкретно в своем коде.
Подождите, зависимость, которая вам не требуется? Я знаю, это звучит странно, но подумайте о плагине Babel, он нуждается в Babel в том смысле, что если его там нет, то он не сможет работать, однако, он может и не требовать Babel явно для чего-либо.
Теперь, потенциально, вы можете добавить Babel в список стандартных зависимостей, однако, при установке плагина, он также попытается установить Babel. И если вы используете, например, NPM, он установит его как локальную зависимость вашего плагина, что означает — он будет дублировать уже существующую установленную Babel для хост-проекта, находящегося в папке плагина.
Когда ты будешь использовать Peer dependencies?
Вы можете прочитать больше о Peer dependencies здесь, однако, поймите, что вы будете использовать их только тогда, когда нужно указать на недостаточно прочную связь с другим проектом.
Другими словами:
Когда она вам нужна, но нет необходимости употреблять ее сразу и однозначно. Тогда это peer dependency.
Когда она вам нужна, но она уже должна быть установлена другим проектом. Тогда это peer dependency.
Примерами того, когда вы хотите использовать peerDependencies, являются:
Babel плагины. Ты хочешь декларировать такие же вещи, как и сам Babel, в качестве равной зависимости (peer dependency).
Express middleware packages (Экспресс-пакеты для промежуточной обработки): Это всего лишь один пример модуля NPM, который требует использования peer dependencies. Вы хотите определить приложение Express как зависимость, но не жесткую, в противном случае каждое промежуточное ПО (middleware) будет каждый раз инсталлировать всю структуру заново.
Если вы собираете Micro Frontend (Микрофронтенд), пытаясь решить, какие зависимости являются внешними (чтобы они не были связаны), а какие нет. Peer dependencies могут быть хорошим решением для этого.
Bit components. Если вы создаете и публикуете front-end компоненты, например, когда вы совместно используете React-компоненты на Bit (Github), вам нужно назначить react библиотеку как peer dependency. Это позволит удостовериться, что нужная библиотека доступна в хостинговом проекте без установки ее в качестве прямой зависимости от него.
Например, взгляните на этот React компонент, который я опубликовал некоторое время назад: это простая кнопка, которую можно выбрать (вы нажимаете на нее и она остается выбранной до тех пор, пока не будет нажата снова).
Снимок экрана component, как видно на Bit’s component hub.
Если вы установите его, вы получите полный код, который содержит файл package.json, в котором перечислены все peer dependencies:
Обратите внимание, что пакет не имеет прямой зависимости, несмотря на то, что для работы ему необходима React-библиотека.
Это также помогает сохранить размер нашего компонента как можно меньше (1KB) — ничего лишнего не добавляется.
Dev Dependencies (Dev зависимости)
Имя говорит обо всем, не так ли? Я имею в виду, что так и должно быть, но когда имена действительно помогают нам, разработчикам, в нашей повседневной работе? Я точно знаю.
Зависимости процесса разработки (Development dependencies) предназначены для того, чтобы содержать только те модули, которые вы используете на этапе разработки вашего проекта.
Да, но есть и другие, например, инструменты для подшивки (linting tools), документация и тому подобное.
Дело в том, что если вы можете запустить проект без использования этого набора инструментов, тогда это dev dependency.
Принцип их работы заключается в том, что зависимости разработки устанавливаются только при запуске npm install или npm link из корневой папки вашего проекта.
Подумайте об этом, в этом случае имеет смысл установить их, так как вы разрабатываете свой собственный проект. Но если вы устанавливаете свой проект внутри другого, то этот процесс будет игнорировать ваши dev dependencies.
Когда ты будешь использовать dev dependencies?
Любая зависимость, которая не требуется для производственного процесса, скорее всего, будет считаться dev dependencies (зависимости развития).
Дело в том, что это отлично работает для всех модулей, кроме вашего хост-проекта.
Все установленные внутри хост-проекта зависимости будут пропускать dev-зависимости модулей во время инсталляции, но всякий раз, когда вы повторно запускаете npm install в хост-проекте, он будет устанавливать заново все пропущенные ранее dev-зависимости модулей.
Поэтому рассмотрим использование Dev зависимостей только для пакетов и модулей, которые будут использоваться другими проектами.
Связанные зависимости (Bundled Dependencies)
Это очень удобно при распространении ваших пакетов в однофайловом формате (помните, что вы также можете указать их URL или локальный путь как стандартную зависимость).
Дополнительные зависимости (Optional dependencies)
Наконец, этот тип зависимостей такой же, как и обычные, они ведут себя и могут быть настроены точно таким же образом. Единственная разница? NPM не выйдет с ошибкой, в случае, если не сможет установить их.
Обычно, когда вы запускаете npm install и процесс не может установить обычную зависимость по какой-либо причине (будь то из-за сбоя в сети, не может найти файл, версию или что-нибудь ещё), то он выдаст ошибку и отменит процесс установки.
Дополнительные зависимости вместо этого позволят NPM продолжать работу. Конечно, вы отвечаете за написание кода, который способен справиться с этими отсутствующими зависимостями, например:
Когда вы будете использовать дополнительные зависимости (optional dependencies)?
Очевидный пример использования этого типа зависимостей — когда вы используете ненадежный источник. Я спрашиваю, зачем это делать? Хороший вопрос. Понятия не имею, но вы определенно можете это сделать, единственная проблема в том, что вам нужно убедиться, что ваш код может с этим справиться, если отсутствуют зависимости.
Но другой интересный вариант использования, это установка действительно необязательных зависимостей (optional dependencies). Я имею в виду, что иногда у вас могут быть специфические для системы зависимости, для таких вещей, как совместимость с CI(Continuous Integration)-платформой. В таких сценариях, когда используете платформу, вы захотите установить эти зависимости, в другом случае, проигнорируете.
Каждый, кто когда-либо пользовался NPM в тот или иной момент, слышал о стандартных и dev-зависимостях. Остальные 3, однако, можно считать менее популярными собратьями.
Хотя некоторые из них действительно сосредоточены на очень специфических сценариях, они могут быть очень удобны, когда с ними сталкиваешься.
Знали ли вы, что у вас так много вариантов? Оставьте комментарий ниже, если вы использовали некоторые из менее распространенных и расскажите нам, как вы их использовали!
Узнать подробнее о курсе «JavaScript Developer. Professional».
Смотреть открытый вебинар по теме «Vue 3 — возможности новой версии одного из самых популярных фронтенд фреймворков».
npm Peer Dependencies
Understanding when and why to use npm peerDependencies
In this article I hope to clarify what npm Peer Dependencies are and especially when you should use them. Peer Dependencies are listed in the package.json file in the peerDependencies object.
To get the most out of this article you should have at least an introductory understanding of npm.
Contents
The Scenario
To keep it real, let’s assume you’re creating an Angular Library or even just a simple JavaScript file that exports some functions.
Your project relies on packages from the npm Registry. These packages are your project’s dependencies.
You want to create your own npm package from your project. So you use npm pack to generate an npm package from your project. You might even decide to publish it to the npm Registry.
Other teams will add your package as a dependency in their own projects. We use Dependencies and Peer Dependencies in package.json to tell these other projects what packages also need to be added for our package to work.
So, at their most basic level here is how Dependencies and Peer Dependencies work:
Dependencies
Dependencies are listed in the package.json file in a dependencies object.
Peer Dependencies
Peer Dependencies are listed in the package.json file in a peerDependencies object.
By adding a package in peerDependencies you are saying:
Adding Dependencies
So, we add dependencies in the package.json file of our npm package folder. Let’s look at exactly how we add packages as dependencies and some examples of package dependencies.
Adding a Dependency
A Dependency is an npm package that our package depends on in order to be able to run. Some popular packages that are typically added as dependencies are lodash, request, and moment.
We add a regular dependency like this:
npm adds the package name and version to the dependencies object in our project’s package.json file.
Adding a Peer Dependency
Peer Dependencies are used to specify that our package is compatible with a specific version of an npm package. Good examples are Angular and React.
To add a Peer Dependency you actually need to manually modify your package.json file. For example, for Angular component library projects, I recommend adding angular/core as a peer dependency. So if you wanted to specify that your package is built for Angular 7, you could include something like this:
About Conflicts
If you have read my previous articles, you know I like you to be able to do this stuff along with me! So feel free to work along with me for this little npm experiment.
conflict-test Project
To get started let’s create a trivial test project. I am going to name mine:
conflict-test
I created it like this:
I then manually edited the package.json file and added two dependencies:
These todd-a and todd-b packages also have their own dependencies:
todd-a
todd-b
So here is the rule:
npm deals with version conflicts by adding duplicate private versions of the conflicted package.
An Approach to Peer Dependencies
Sometimes, having two versions of the same package is fine. However, some packages will cause conflicts when there are two different versions of them in the same code base.
For example, assume our component library was created using Angular 5. We wouldn’t want our package adding another completely different version of angular/core when someone adds it as a dependency to their Angular 6 application.
The key is:
We don’t want our library adding another version of a package to node-modules when that package could conflict with an existing version and cause problems.
peerDependencies or dependencies?
So this brings us to the main question for our dependencies:
When my package depends on another package, should I put it in dependencies or peerDependencies?
Well, as with most technical questions: it depends.
Peer Dependencies express compatibility. For example, you will want to be specific about which version of Angular your library is compatible with.
The Guidelines
Favor using Peer Dependencies when one of the following is true:
Angular as a Dependency
Given that you are going to specify in your documentation that your library is a set of Angular Components and Services, you may be asking the question:
“Do I even need to specify angular/core as a dependency? If someone is using my library, they will already have an existing Angular project.”
Yes, we can usually assume that for our Angular specific library the Workspace will already have the Angular packages available. Hence, technically we wouldn’t need to bother adding them to our list of dependencies.
However, we really do want to tell the developer which Angular versions our library is compatible with. So I recommend the following approach:
This way developers will see a warning if they try to use your Angular 7 library in their Angular 6 project. Don’t bother adding the other Angular packages. You can assume if they have angular/core, they have the other Angular libraries.