johnymkp, ну собственно так и решают, пир-зависимости с указанием версии
Алексей Уколов, можно и пользоваться, но только тем что тебе передали, т.е. садовник не несёт усадьбу с собой, а пользуется возможностями (открывает воду) той куда его наняли.
Т.е. не вызывает явно require('усадьба'), а скорее у него есть init(usadba) { /* запомним на какой усадьбе работаем */ }
johnymkp, но в целом как обычно никакой строгой границы не существует. Плагин тоже может вызывать базовый пакет, но по сути оставаться плагинов и описывать базовый пакет как peerDependencies.
Я для себя определяю плагин примерно так:
- базовый пакет должен использоваться приложением напрямую (eslint, webpack, typescript, ...), а плагин это дополнительная плюшка которая каким-то образом добавляется к базовому пакету (обычно в виде конфига);
- несколько плагинов обязаны использовать один базовый пакет, т.е. не может быть ситуации что PlugA использует Foobar@1, а PlugB использует Foobar@2, установка зависимостей должна ругаться.
- сам по себе плагин практически бесполезен (конфиг eslint без eslint не нужен, плагин вебпака без вебпака бесполезен).
johnymkp, естественный пример плагина. У вас есть eslint и вы написали себе конфиг для него.
Что бы не копипастить этот конфиг в каждый свой проект, вы хотите оформить его в виде npm-пакета.
И получается, что по сути в вашем пакете будет один JSON-файл с конфигом и никаких явных зависимостей от eslint, вы же не вызываете его явно.
Но при этом ваш пакет без eslint не особо полезен, поэтому вы пишете ему в peerDependencies что нужен eslint. Ну и поскольку вы использовали какие-то правила которые есть только eslint@9, то вы указываете именно эту версю (диапазон версий) в peerDependencies.
И как видите никакого явного вызова eslint в пакете нет, т.е. тот кто будет использовать этот пакет будет сам указывать eslint-у что надо ещё использовать и конфиги из этого пакета.
Алексей Уколов, ну с npm всё возможно. Он же попробует сплющить дерево и Foobar попадёт в область видимости приложения. Это прямо-таки стандартная ошибка новичков и не только.
Особенно весело когда изначально у тебя были
PlugA@1.0.0 dep Foobar@1.0.0
PlugB@1.0.0 dep Foobar@1.0.0
И всё радостно на диске лежало в виде трёх папок на одном уровне
но поскольку в реальности Plug2 явно не вызывает Foobar, то в итоге он будет работать с Foobar@1 из верхнего уровня и привет два часа счастливого дебага.
Ещё одно важное свойство peerDependencies это проверка совместимости разных версий.
Если у вас есть PlugA который работает с Foobar@1.0.0 и PlugB который работает с Foobar@2.0.0, то peerDependencies в каждом их них покажут конфликт при установке и вам надо будет это как-то починить.
А если вместо peerDependencies указать просто dependencies, то каждый из них поставит себе свою версию Foobar и потом вы будет долго искать фантомные баги.
Собственно одноразовый блокнот это и есть идеальное шифрование.
А от «угадывания» исходного сообщения (а это и есть ваша единственная претензия к блокноту) защититься невозможно. Угадать сообщение можно и вовсе не имея на руках никого зашифрованного сообщения.
