Как исправить предупреждение npm unmet peer dependency?

Использование файла «package.json»

Лучший способ управления локально установленными пакетами — это использование файла «package.json», который должен иметь как минимум
name и
version.

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

Поле
version определяет версию в формате x.x.x.

Пример:

JavaScript

{
«name»: «my-awesome-package»,
«version»: «1.0.0»
}

1
2
3
4

{

«name»»my-awesome-package»,

«version»»1.0.0»

}

Создать «package.json» можно командой с консоли:

npm init

Эта команда проведёт вас через процесс создания «package.json» в стиле вопрос-ответ.

Установка пакетов npm

Существует два способа установки пакетов npm: локально и глобально.

Если вы хотите использовать пакет из своего модуля с помощью чего-нибудь вроде
require от Node.js, то вам нужно установить пакет локально командой:

npm install <имя_пакета>

1	npm install <имя_пакета>

Эта команда создаст каталог «node_modules» в текущем рабочем каталоге и скачает туда указанный пакет.

Для проверки этой команды вы можете выполнить:

npm install lodash

1	npm install lodash

Затем проверьте, что у вас появился каталог «node_modules» с подкаталогом «lodash».

Если у вас не было файла «package.json» в текущем каталоге, то устанавливается последняя версия, если же файл «package.json» присутствует, то устанавливается последняя версия, удовлетворяющая правилам в этом файле.

Публикация пакета npm

Для начала вам нужно создать пользователя в репозитории npm:

npm adduser

1	npm adduser

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

npm login

Для публикации пакета используйте команду:

npm publish

1	npm publish

Имейте в виду, что опубликовано будет всё, что не добавлено в игнорируемые в «.gitignore» или «.npmignore».

Перейдите на
https://npmjs.com/package/<package>. Вы должны увидеть информацию о вашем пакете.

Для обновления версии используйте одну из команд:

npm update patch

1	npm update patch

или

npm update minor

1	npm update minor

или

npm update major

1	npm update major

А затем опубликуйте его снова:

npm publish

1	npm publish

Зависимости от других пакетов

Для указания зависимости от других пакетов используются поля
dependencies и
devDependencies в «package.json», которые указывают зависимости для production среды и development соответственно. Для добавления зависимостей проще использовать флаги
—save и
—save-dev у
npm install, которые сохраняют зависимость в «package.json» для production и development среды.

npm install <имя_пакета> —save

1	npm install <имя_пакета> —save

npm install <имя_пакета> —save-dev

1	npm install <имя_пакета> —save-dev

Пример «package.json» с зависимостями:

package.json

JavaScript

{
«name»: «my_package»,
«version»: «1.0.0»,
«dependencies»: {
«my_dep»: «^1.0.0»
},
«devDependencies» : {
«my_test_framework»: «^3.1.0»
}
}

1
2
3
4
5
6
7
8
9
10

{

«name»»my_package»,

«version»»1.0.0»,

«dependencies»{

«my_dep»»^1.0.0»

«devDependencies»{

«my_test_framework»»^3.1.0»

}

Начало работы

Логично начать с создания директории для нового проекта.

Я буду работать над сайтом HeiHei.ru
поэтому назову папку heihei

mkdir heihei

Перейдём в созданную директорию

cd heihei

Убедимся, что в новой папке пусто

Теперь выполним важнейшую для будущей разработки команду

$ npm init

This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.
See `npm help json` for definitive documentation on these fields
and exactly what they do.
Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.
Press ^C at any time to quit.
package name: (my-project)

npm предложит заполнить информацию о проекте. Появятся следующие поля:

name: (heihei)
version: (1.0.0)
description:
entry point: (index.js)
test command:
git repository:
keywords:
author:
license: (ISC)

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

Если предварительно привязать директорию к удалённому репозиторию
GIT
то npm при инициализации это увидит и сам заполнит пункт git repository.

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

В конце должно появиться подобное сообщение. Нажимаем Enter ещё раз.

About to write to C:\Users\ao\Desktop\Sites\heihei\package.json:
{
«name»: «heihei»,
«version»: «1.0.0»,
«description»: «»,
«main»: «index.js»,
«scripts»: {
«test»: «echo \»Error: no test specified\» && exit 1″
},
«author»: «»,
«license»: «ISC»
}
Is this OK? (yes)

Проверим, что появилось в нашей папке после инициализации

package.json

package.json
это файл, который будет хранить в себе список установленных пакетов и их версии.

Сразу после инициализации он содержит только информацию о проекте

В мире

Python

похожие задачи решают

venv

freeze

Поддержка зависимостей

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

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

Получение зависимостей

Файл package.json поддерживает зависимости вашего приложения и вам не надо коммитить зависимость в своё хранилище на Git. Тем, кто клонирует свой проект, требуется задать зависимости. Их установка очень простая:

После выполнения этой команды в консоли вы увидите загрузку пакетов из Интернета!

Node.js

The Scenario Link to this section

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 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
Link to this section

Dependencies are listed in the package.json file in a object.

When you add a package in , you are saying:

My code needs this package to run.
If this package doesn’t already exist in my node_modules directory, then add it automatically.
Furthermore, add the packages that are listed in the package’s dependencies. These packages are called transitive dependencies.

Peer Dependencies
Link to this section

Peer Dependencies are listed in the package.json file in a object.

By adding a package in you are saying:

My code is compatible with this version of the package.
If this package already exists in node_modules, do nothing.
If this package doesn’t already exist in the node_modules directory or it is the wrong version, don’t add it. But, show a warning to the user that it wasn’t found.

Adding Dependencies Link to this section

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
Link to this section

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:

<>Copy

npm adds the package name and version to the object in our project’s package.json file.

<>Copy

Some of you might remember the old days when we had to use the flag to get npm to update the in package.json. Thankfully, we don’t need to do that anymore.

Adding a Peer Dependency
Link to this section

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 as a peer dependency. So if you wanted to specify that your package is built for Angular 7, you could include something like this:

<>Copy

The Problem: Plugins

There’s one use case where this falls down, however: plugins. A plugin package is meant to be used with another «host»
package, even though it does not always directly use the host package. There are many examples of this pattern in the
Node.js package ecosystem already:

Grunt
Chai plugins
LevelUP plugins
Express
Winston transports

Even if you’re not familiar with any of those use cases, surely you recall «jQuery plugins» from back when you were a
client-side developer: little s you would drop into your page that would attach things to
for your later convenience.

In essence, plugins are designed to be used with host packages. But more importantly, they’re designed to be used with
particular versions of host packages. For example, versions 1.x and 2.x of my plugin work with
version 0.5, whereas versions 3.x work with 1.x. Or, in the faster-paced and less-semver–friendly world of
Grunt plugins, version 0.3.1 of works with 0.4.0rc4, but breaks when used with
0.4.0rc5 due to removed APIs.

As a package manager, a large part of npm’s job when installing your dependencies is managing their versions. But its
usual model, with a hash in , clearly falls down for plugins. Most plugins never actually
depend on their host package, i.e. grunt plugins never do , so even if plugins did put down their host
package as a dependency, the downloaded copy would never be used. So we’d be back to square one, with your application
possibly plugging in the plugin to a host package that it’s incompatible with.

Even for plugins that do have such direct dependencies, probably due to the host package supplying utility APIs,
specifying the dependency in the plugin’s would result in a dependency tree with multiple copies of the
host package—not what you want. For example, let’s pretend that 0.2.3 specified in
its hash, since that’s the latest version it was tested against. As an app developer, you want the
latest and greatest stuff, so you look up the latest versions of and of , putting them in your
as

But now, running results in the unexpected dependency graph of

I’ll leave the subtle failures that come from the plugin using a different Winston API than the main application to
your imagination.

Angular as a Dependency Link to this section

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:

Good question!

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:

Add at least angular/core for the compatible Angular version to your .

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.

The Guidelines

Favor using Peer Dependencies when one of the following is true:

Having multiple copies of a package would cause conflicts
The dependency is visible in your interface
You want the developer to decide which version to install

Let’s take the example of . Obviously, if you are creating an Angular Library, is going to be a very visible part of your library’s interface. Hence, it belongs in your .

However, maybe your library uses Moment.js internally to process some time related inputs. Moment.js most likely won’t be exposed in the interface of your Angular Services or Components. Hence, it belongs in your .

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:

Good question!

However, we really do want to tell the developer which Angular versions our library is compatible with. So I recommend the following approach:

In Conclusion

When in doubt you should probably lean toward using . This lets the users of your package make their own choice about which packages to add.

Использование npm

Теперь, когда npm установлен, все зарегистрированные пакеты являются просто командой в консоли. Для базовой установки пакета выполните:

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

Чтобы сделать это, вам нужно добавить флаг -g в процессе установки:

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

Использование npm с проектом

Наиболее распространённым примером использования npm является поддержка манифеста зависимостей для вашего проекта. Всё это хранится в файле package.json.

Вы можете создать этот файл самостоятельно, хотя также есть методы сгенерировать этот файл. В любой папке просто запустите npm init и в консоли вы пройдёте через ряд вопросов, в результате получите что-то вроде такого:

Если в вашем проекте уже содержится package.json, добавить в него пакет очень легко с помощью npm install. Просто включите флаг —save в команду следующим образом:

Добавление Grunt в проект обновит package.json, добавив объект dependencies в файл:

В добавление к этому, если вы хотите указать зависимость только для разработки, а не для рабочего проекта, то передайте флаг -dev:

Добавив Gulp как зависимость для разработки, в файле package.json появится объект devDependencies:

Узнайте больше о npm

npm удивительно сложная утилита, когда дело доходит до управления пакетами. Смотрите эту шпаргалку по npm для получения дополнительной подробной информации.

Узнайте больше о package.json

package.json содержит много особенностей. Чтобы узнать больше о том, как это всё работает, посетите — удивительный инструмент для обучения.

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.

"peerDependencies": {  "@angular/core": "^7.0.0"}

About Conflicts

I get a lot of questions about whether a certain npm package should go into or into . The key to making this decision involves understanding how npm deals with version 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.

Идея версионирования: патчи, минорные и мажорные версии

Идея использования трёх чисел, разделённых точками, в качестве версии состоит в следующем (например, если текущий пакет 1.0.0):

Патчи или исправления ошибок и незначительные изменения увеличивают последнее число (1.0.1).
Минорные версии. Новые возможности, которые не ломают старый код увеличивают второе число (1.1.0).
Мажорные версии. Изменения, ломающие совместимость со старым кодом увеличивают самое первое число (2.0.0).

При указании необходимой версии зависимости в «package.json» можно указывать диапазоны:

1.0, 1.0.x или ~1.0.4 будет использовать последнюю версию патча с исправлениями ошибок (для третьего варианта начиная с версии 1.0.4).
1, 1.x или ^1.0.4 будет использовать последнюю минорную версию.
* или x всегда будет использовать последнюю версию.

Установка Node

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

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

Installing Node and npm — хорошая статья обо всех способах установки

Обратите внимание на Шаг 4, в котором высказываются некоторые довольно твёрдые убеждения об установке

gist иллюстрирует ряд способов установки Node.

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

Установка определённой версии пакета

Установим ещё один пакет и поговорим о его возможных версиях

$ npm install normalize.css

Если package.json не содержит записи о normalize.css то будет установлена последняя стабильная версия.

Если в package.json указана версия, будет установлена она.

Если Вы хотите установить какую-то определённую версию, укажите её в package.json либо
введите @номер_версии при установке.

Например npm install normalize.css@8.0.1

npm WARN [email protected] No description
npm WARN [email protected] No repository field.
+ [email protected]
added 1 package and audited 2 packages in 0.523s
found 0 vulnerabilities

Посмотрим содержимое файла package.json и заодно узнаем какие версии пакетов установлены

$ vi package.json

About Conflicts Link to this section

I get a lot of questions about whether a certain npm package should go into or into . The key to making this decision involves understanding how npm deals with version 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
Link to this section

To get started let’s create a trivial test project. I am going to name mine:

I created it like this:

I then manually edited the package.json file and added two dependencies:

These and packages also have their own dependencies:

todd-a
Link to this section

todd-b
Link to this section

The thing I want you to notice here is that and use the same version of . But, they have a version conflict for : uses todd-child version 1.0.0 uses todd-child version 2.0.0

Now I know that, like me, you are keenly interested to see how npm handles this version conflict. In my main project I run . As we would expect, npm magically installs the and packages in our node_modules folder. It also adds the packages that they depend on (the transitive dependencies). So after running we take a look at the node_modules folder. It looks like this:

The interesting thing about this is that our project has one copy of . But, it has two copies of . Notice that gets its own private copy of .

So here is the rule:

Проблема с зависанием при установке npm решена

http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>style=»clear:both;»>

npm install использует по умолчаниюhttp://www.npmjs.org Адресация зависимости установки, если сеть не настроена через стену, иногда сторонний пакет зависимостей может зависнуть или установка завершится ошибкой. Используйте внутренние зеркальные сайты для решения

Решение 1:

Выполните следующую команду, чтобы изменить файл конфигурации .npmrc.

Решение 2:

vim изменить конфигурацию .npmrc, изменить Атрибут — отечественное зеркало-источник.https://npm.taobao.org

Интеллектуальная рекомендация

1. Для реальных сигналов (для понимания): A (ω) является соотношением амплитуды выходного сигнала и амплитуды входного сигнала, называемого частотой амплитуды. Φ (ω) — это разница межд…

Один. вести Многие люди задавали некоторые вопросы о создании проекта Flex + LCDS (FDS) в сообщениях и группах. Из-за операции ее трудно четко объяснить, поэтому я написал простой учебник (я обещал эт…

package com.example.phonehttp; import android.os.Bundle; import android.os.Handler; import android.app.Activity; import android.widget.ScrollView; import android.widget.TextView; public class MainActi…

Он предназначен для реализации подкласса того же родительского класса с родительским классом. Полиморфизм Один и тот же ссылочный тип использует разные экземпляры для выполнения разных операций; Идея …

тема: Объедините два упорядоченных слоя в новый заказанный список и возврат. Новый список состоит из всех узлов двух связанных списков, данных сплавным. Пример: Анализ: два связанных списка состоит в …

Вам также может понравиться

D. Самая ценная строка Пример ввода 2 2 aa aaa 2 b c Образец вывода aaa c На самом деле, будучи задетым этим вопросом, вы должны быть осторожны. После инвертирования строки, если две строки имеют один…

Given a 2D integer matrix M representing the gray scale of an image, you need to design a smoother to make the gray scale of each cell becomes the average gray scale (rounding down) of all the 8 surro…

calc () может быть очень незнакомым для всех, и трудно поверить, что calc () является частью CSS. Поскольку он выглядит как функция, почему он появляется в CSS, поскольку это функция? Этот момент такж…

Основываясь на дереве регрессии, сформированном CART, а также на предварительной и последующей обрезке дерева, код выглядит следующим образом:…

Откат Обновление в режиме онлайн с версии Centos (CentOS Linux версии 7.3.1611 (Core) до CentOS Linux версии 7.5.1804 (Core)) # ошибка соединения yum-ssh после обновления yexpected key exchange group …

An Approach to Peer Dependencies Link to this section

As we saw from our experiment with npm version conflicts, if you add a package to your , there is a chance it may end up being duplicated in node_modules.

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 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.

or dependencies?

So this brings us to the main question for our dependencies:

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
Link to this section

Favor using Peer Dependencies when one of the following is true:

Having multiple copies of a package would cause conflicts
The dependency is visible in your interface
You want the developer to decide which version to install

Let’s take the example of . Obviously, if you are creating an Angular Library, is going to be a very visible part of your library’s interface. Hence, it belongs in your .

todd-b

"dependencies": {    "lodash": "^4.17.11",    "todd-child": "^2.0.0"  }

The thing I want you to notice here is that and use the same version of . But, they have a version conflict for : uses todd-child version 1.0.0 uses todd-child version 2.0.0

node_modules├── lodash 4.17.11├── todd-a 1.0.0├── todd-b 1.0.0│   └── node_modules│       └── todd-child 2.0.0└── todd-child 1.0.0

The interesting thing about this is that our project has one copy of . But, it has two copies of . Notice that gets its own private copy of .

So here is the rule:

An Approach to Peer Dependencies

As we saw from our experiment with npm version conflicts, if you add a package to your , there is a chance it may end up being duplicated in node_modules.

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.

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.

The Solution: Peer Dependencies

What we need is a way of expressing these «dependencies» between plugins and their host package. Some way of saying, «I
only work when plugged in to version 1.2.x of my host package, so if you install me, be sure that it’s alongside a
compatible host.» We call this relationship a peer dependency.

The peer dependency idea has been kicked around for literally
years. After
to get this done «over the weekend» nine
months ago, I finally found a free weekend, and now peer dependencies are in npm!

Specifically, they were introduced in a rudimentary form in npm 1.2.0, and refined over the next few releases into
something I’m actually happy with. Today Isaac packaged up npm 1.2.10 into
Node.js 0.8.19, so if you’ve installed the latest version of
Node, you should be ready to use peer dependencies!

As proof, I present you the results of trying to install 0.11.6 with npm
1.2.10:

As you can see, depends on two Flatiron-related packages, which themselves peer-depend on conflicting versions
of Flatiron. Good thing npm was around to help us figure out this conflict, so it could be fixed in version 0.11.7!

Using Peer Dependencies

Peer dependencies are pretty simple to use. When writing a plugin, figure out what version of the host package you
peer-depend on, and add it to your :

Now, when installing , the package will come along with it. And if later you try to install
another Chai plugin that only works with 0.x versions of Chai, you’ll get an error. Nice!

UPDATE: npm versions 1, 2, and 7 will automatically install peerDependencies if they are not explicitly depended upon higher in the dependency tree. For npm versions 3 through 6, you will receive a warning that the peerDependency is not installed instead.

One piece of advice: peer dependency requirements, unlike those for regular dependencies, should be lenient. You
should not lock your peer dependencies down to specific patch versions. It would be really annoying if one Chai plugin
peer-depended on Chai 1.4.1, while another depended on Chai 1.5.0, simply because the authors were lazy and didn’t spend
the time figuring out the actual minimum version of Chai they are compatible with.

The best way to determine what your peer dependency requirements should be is to actually follow
semver. Assume that only changes in the host package’s major version will break your plugin. Thus,
if you’ve worked with every 1.x version of the host package, use or to express this. If you depend on
features introduced in 1.5.2, use .

Now go forth, and peer depend!