Чому, наприклад, плагін Grunt визначає свою залежність від grunt як " однорангову залежність "?

Чому плагін не може мати Grunt як власну залежність у grunt-plug / node_modules ?

Тут описані залежності від рівних: https://nodejs.org/en/blog/npm/peer-dependitions/

Але я насправді не розумію.

Приклад

На даний момент я працюю з AppGyver Steroids, який використовує завдання Grunt для зведення моїх вихідних файлів у / dist / папку для подання на локальному пристрої. Я зовсім новий в npm та бурчання, тому хочу повністю зрозуміти, що відбувається.

Поки що я розумію:

[rootfolder] /package.json повідомляє npm, що залежить від grunt-steroidsпакету npm для розробки:

  "devDependencies": {
    "grunt-steroids": "0.x"
  },

Добре. Запуск npm install у [rootfolder] виявляє залежність та встановлює grunt-steroids у [rootfolder] / node_modules / grunt-steroids .

Потім Npm зчитує [rootfolder] /node_modules/grunt-steroids/package.json, щоб він міг встановлювати grunt-steroidsвласні залежності:

"devDependencies": {
    "grunt-contrib-nodeunit": "0.3.0",
    "grunt": "0.4.4"
  },
"dependencies": {
    "wrench": "1.5.4",
    "chalk": "0.3.0",
    "xml2js": "0.4.1",
    "lodash": "2.4.1"
  },
"peerDependencies": {
    "grunt": "0.4.4",
    "grunt-contrib-copy": "0.5.0",
    "grunt-contrib-clean": "0.5.0",
    "grunt-contrib-concat": "0.4.0",
    "grunt-contrib-coffee": "0.10.1",
    "grunt-contrib-sass": "0.7.3",
    "grunt-extend-config": "0.9.2"
  },

Пакети " залежності " встановлюються в [rootfolder] / node_modules / grunt-steroids / node_modules, що для мене є логічним.

" DevDependitions " не встановлено, що, я впевнений, контролюється npm виявленням, яке я просто намагаюся використовувати grunt-steroids, а не розвиватися на ньому.

Але тоді у нас є " peerDependitions ".

Вони встановлені в [rootfolder] / node_modules , і я не розумію, чому там, а не в [rootfolder] / node_modules / grunt-steroids / node_modules, щоб уникнути конфліктів з іншими плагінами grunt (або будь-яким іншим)?

TL; DR: ^{[1] -} peerDependencies це залежності, які піддаються (і очікується, що їх буде використовувати) споживчий код, на відміну від "приватних" залежностей, які не піддаються впливу, і є лише деталями реалізації.

Проблема залежностей від однолітків вирішується

Модульна система NPM є ієрархічною. Однією з великих переваг для більш простих сценаріїв є те, що при встановленні пакету npm цей пакет приносить з собою власні залежності, щоб він вийшов з коробки.

Але проблеми виникають, коли:

• І ваш проект, і деякий модуль, який ви використовуєте, залежать від іншого модуля.
• Три модулі повинні говорити один з одним.

У прикладі

Скажімо, ви будуєте, YourCoolProjectі ви використовуєте і те, JacksModule 1.0і інше JillsModule 2.0. І припустимо, що це JacksModuleтеж залежить JillsModule, скажімо, від іншої версії 1.0. Поки ці 2 версії не відповідають, немає жодної проблеми. Те, що JacksModuleвикористовується JillsModuleпід поверхнею, - лише деталь реалізації. Ми збираємося JillsModuleвдвічі, але це невелика ціна, яку потрібно платити, коли ми отримуємо стабільне програмне забезпечення поза коробкою.

Але що робити, якщо якимось чином JacksModuleвикриває свою залежність JillsModule. Він приймає екземпляр, JillsClassнаприклад ... Що відбувається, коли ми створюємо new JillsClassвикористовувану версію 2.0бібліотеки і передаємо її разом jacksFunction? Все пекло зірветься! Прості речі на кшталт jillsObject instanceof JillsClassнесподівано повернуться, falseтому що jillsObjectнасправді є примірником іншої JillsClass , 2.0версії.

Як це вирішують залежності від рівних

Вони кажуть нпм

Мені потрібен цей пакет, але мені потрібна версія, яка є частиною проекту, а не якась версія, приватна для мого модуля.

Коли npm побачить, що ваш пакет встановлюється в проект, у якого немає такої залежності, або у нього є несумісна версія , він попередить користувача в процесі встановлення.

Коли слід використовувати одноліткові залежності?

• Коли ви будуєте бібліотеку, яку використовуватимуть інші проекти, і
• Ця бібліотека використовує деякі інші бібліотеки та
• Ви очікуєте, що користувач також повинен працювати з цією іншою бібліотекою

Поширені сценарії - плагіни для більших рамок. Подумайте про такі речі, як Gulp, Grunt, Babel, Mocha тощо. Якщо ви пишете плагін Gulp, ви хочете, щоб цей плагін працював з тим самим Gulp, який використовує проект користувача, а не з вашою приватною версією Gulp.

Анотації

1. Надто довго; не читав. Використовується для позначення короткого резюме для тексту, який вважається занадто довгим.

Я рекомендую вам спочатку прочитати статтю ще раз. Це трохи заплутано, але приклад із Winston-mail показує вам відповідь, чому:

Наприклад, зробимо вигляд, що winston-mail@0.2.3вказано "winston": "0.5.x"в його "dependencies"об'єкті, оскільки це остання версія, на яку було протестовано. Як розробник програми, ви хочете отримати найновіші та найкращі речі, тому ви шукаєте найновіші версії winstonта winston-mailта додаєте їх у свій package.json як

{
  "dependencies": {  
    "winston": "0.6.2",  
    "winston-mail": "0.2.3"  
  }  
}

Але тепер, запуск npm встановлення призводить до несподіваного графіка залежності

├── winston@0.6.2  
└─┬ winston-mail@0.2.3                
  └── winston@0.5.11

У цьому випадку можлива наявність декількох версій пакета, які могли б викликати деякі проблеми. Рівні залежності дозволяють розробникам npm переконатися, що користувач має певний модуль (у кореневій папці). Але ви правильні з тим, що опис однієї конкретної версії пакета призведе до проблем з іншими пакетами, використовуючи інші версії. Це питання стосується розробників npm, як зазначено в статтях

Порада : вимоги до рівних залежностей, на відміну від звичайних залежностей, повинні бути поблажливішими . Ви не повинні блокувати свої однорангові залежності до конкретних версій патчу.

Тому розробники повинні дотримуватися semver для визначення peerDependitions. Ви повинні відкрити випуск для пакету грунтових стероїдів на GitHub ...

peerDependencies пояснено найпростішим можливим прикладом:

{
  "name": "myPackage",
  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }
}


{
  "name": "foo"
  "peerDependencies": {
    "react": "^16.0.0"
  }
}

запуск npm install у myPackage видасть помилку, оскільки він намагається встановити версію React ^15.0.0AND foo, сумісну лише з React ^16.0.0.

peerDependitions НЕ встановлено.