플러그인에 대해 npm에서 피어 종속성을 사용하는 이유는 무엇입니까?

플러그인에 대해 npm에서 피어 종속성을 사용하는 이유는 무엇입니까?

---

예를 들어, Grunt 플러그인이 grunt에 대한 종속성을 " 피어 종속성 " 으로 정의하는 이유는 무엇 입니까?

플러그인이 grunt-plug / node_modules 에서 자체 종속성으로 Grunt를 가질 수없는 이유는 무엇 입니까?

피어 종속성은 https://nodejs.org/en/blog/npm/peer-dependencies/에 설명되어 있습니다.

그러나 나는 그것을 정말로 얻지 못한다.

예

현재 Grunt 작업을 사용하여 소스 파일을 / dist / 폴더에 빌드하여 로컬 장치에서 제공하는 AppGyver 스테로이드와 함께 일하고 있습니다. 나는 npm에 아주 새롭고 grunt이므로 무슨 일이 일어나고 있는지 완전히 이해하고 싶습니다.

지금까지 나는 이것을 얻는다 :

[rootfolder] /package.json 은 npm grunt-steroids에게 개발 을 위해 npm 패키지에 의존 한다고 알려줍니다 .

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

괜찮아. [rootfolder] 에서 npm install을 실행 하면 종속성을 감지하고 [rootfolder] / node_modules / grunt-steroids에 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에 설치되어 있으며 이는 나에게 논리적입니다.

" devDependencies "가 설치되어 있지 않습니다. 확실하게 npm을 사용하여 감지하려고 시도하고 grunt-steroids개발하지 않는 것으로 감지 됩니다.

그러나 " peerDependencies "가 있습니다.

이것들은 [rootfolder] / node_modules에 설치되어 있으며 , 다른 root 플러그인 (또는 무엇이든)과의 충돌을 피하기 위해 [rootfolder] / node_modules / grunt-steroids / node_modules에 왜 존재하지 않는지 이해하지 못 합니까?

---

TL; DR : ^[1] peerDependencies 은 노출 되지 않은 "비공개" 종속성 과 달리 소비 코드에 노출되고 사용되는 것으로 예상되는 종속성을위한 것이며 구현 세부 사항 일뿐입니다.

동료 상호 의존성 문제 해결

NPM의 모듈 시스템은 계층 적입니다. 보다 간단한 시나리오의 가장 큰 장점 중 하나는 npm 패키지를 설치할 때 해당 패키지에 고유 한 종속성이 있으므로 즉시 사용할 수 있다는 것입니다.

그러나 다음과 같은 경우에 문제가 발생합니다.

• 프로젝트와 사용중인 일부 모듈은 다른 모듈에 따라 다릅니다.
• 세 개의 모듈은 서로 대화해야합니다.

예에서

하자 당신이 구축하고 말하는 YourCoolProject당신이 모두를 사용 JacksModule 1.0하고 JillsModule 2.0. 그리고에 JacksModule의존 JillsModule하지만 다른 버전에 의존 한다고 가정 해 봅시다 1.0. 이 두 버전이 맞지 않는 한 아무런 문제가 없습니다. 표면 아래에서 JacksModule사용 되는 사실 JillsModule은 구현 세부 사항입니다. 우리는 JillsModule두 번 번들을 제공 하지만 안정적인 소프트웨어를 즉시 얻을 때 지불해야 할 가격은 적습니다.

그러나 이제는 어떤 식 으로든 JacksModule의존성을 드러내면 어떨까요 JillsModule? JillsClass예를 들어 인스턴스를 받아들 입니다. 라이브러리를 new JillsClass사용하는 버전 2.0을 만들어 전달하면 jacksFunction어떻게됩니까? 모든 지옥은 풀릴 것이다! 간단한 것을 좋아 jillsObject instanceof JillsClass갑자기 돌아갑니다 false때문에 jillsObject실제의 인스턴스 인 다른 JillsClass 의 2.0버전.

동료 종속성이이를 해결하는 방법

그들은 npm에게 말한다

이 패키지가 필요하지만 내 모듈 전용 버전이 아니라 프로젝트의 일부인 버전이 필요합니다.

When npm sees that your package is being installed into a project that does not have that dependency, or that has an incompatible version of it, it will warn the user during the installation process.

When should you use peer dependencies?

• When you are building a library to be used by other projects, and
• This library is using some other library, and
• You expect/need the user to work with that other library as well

Common scenarios are plugins for larger frameworks. Think of things like Gulp, Grunt, Babel, Mocha, etc. If you write a Gulp plugin, you want that plugin to work with the same Gulp that the user's project is using, not with your own private version of Gulp.

---

Annotations

1. Too long; didn't read. Used to indicate a short summary for a text that one has deemed too long.

---

I would recommend you to read the article again first. It's a bit confusing but the example with winston-mail shows you the answer why:

For example, let's pretend that winston-mail@0.2.3 specified "winston": "0.5.x" in its "dependencies" object because 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 winston and of winston-mail and put them in your package.json as

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

But now, running npm install results in the unexpected dependency graph of

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

In this case, it is possible to have multiple versions of a package which would cause some issues. Peer dependencies allow npm developers to make sure that the user has the specific module (in the root folder). But you're correct with the point that describing one specific version of a package would lead to issues with other packages using other versions. This issue has to do with npm developers, as the articles states

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.

Therefore developers should follow semver for defining peerDependencies. You should open an issue for the grunt-steroids package on GitHub...

---

peerDependencies explained with the simplest example possible:

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


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

running npm install in myPackage will throw an error because it is trying to install React version ^15.0.0 AND foo which is only compatible with React ^16.0.0.

peerDependencies are NOT installed.

참고URL : https://stackoverflow.com/questions/26737819/why-use-peer-dependencies-in-npm-for-plugins