npm package.json 파일의 종속성, devDependencies 및 peerDependencies의 차이점은 무엇입니까?

질문자 :Vitalii Korsakov

이 문서는 내 질문에 매우 좋지 않은 답변을 제공합니다. 나는 그 설명을 이해하지 못했다. 누군가가 더 간단한 단어로 말할 수 있습니까? 간단한 단어를 선택하기 어렵다면 예를 들어볼까요?

EDIT 는 또한 밀접하게 관련되어 혼동을 일으킬 수 있는 peerDependencies

중요한 행동 차이 요약:

• dependencies 은 둘 다에 설치됩니다.

  • package.json 이 포함된 디렉토리에서 npm install
  • npm은 다른 디렉토리에 npm install $package

• devDependencies 는 다음과 같습니다.

  • --production 플래그를 전달하지 않는 한 package.json 을 포함하는 디렉토리의 npm install 에도 설치됩니다 (Gayan Charith의 답변에 찬성 투표 ).
  • --dev 옵션을 제공하지 않는 한 npm install "$package" 에 설치되지 않습니다.
  • 전이적으로 설치되지 않습니다.

• peerDependencies :

  • 3.0 이전: 누락된 경우 항상 설치되고 호환되지 않는 여러 버전의 종속성이 다른 종속성에서 사용될 경우 오류가 발생합니다.
  • 3.0에서 시작될 것으로 예상됨 (테스트되지 않음): npm install 에서 누락된 경우 경고를 표시하고 수동으로 종속성을 직접 해결해야 합니다. 실행할 때 종속성이 없으면 오류가 발생합니다( @nextgentech 에서 언급). 다음과 같이 잘 설명되어 있습니다. https://flaviocopes.com/npm-peer-dependencies/
  • 버전 7에서 자동으로 해결할 수 없는 업스트림 종속성 충돌이 없으면 peerDependencies가 자동으로 설치됩니다.

• 전이성( Ben Hutchison 언급):

  • dependencies 은 전이적으로 설치됩니다. A에 B가 필요하고 B에 C가 필요하면 C가 설치되고, 그렇지 않으면 B가 작동하지 않고 A도 작동하지 않습니다.

  • devDependencies 는 전이적으로 설치되지 않습니다. 예를 들어 A를 테스트하기 위해 B를 테스트할 필요가 없으므로 B의 테스트 종속성을 생략할 수 있습니다.

여기에서 논의되지 않은 관련 옵션:

• bundledDependencies 다음과 같은 질문에 설명되어 있습니다 : NPM 정상 종속 이상 bundledDependencies의 장점
• optionalDependencies ( Aidan Feldman이 언급)

devDependencies

dependencies 은 실행하는 데 필요하고 devDependencies 는 개발에만 필요합니다(예: 단위 테스트, CoffeeScript에서 JavaScript로 변환, 축소, ...

패키지를 개발하려는 경우 패키지를 다운로드(예: git clone package.json 을 포함하는 루트로 이동하여 다음을 실행합니다.

 npm install

실제 소스가 있으므로 개발하려는 것이 분명하므로 기본적으로 dependencies (개발하려면 실행해야 하므로)과 devDependency 종속성도 모두 설치됩니다.

그러나 사용하기 위해 패키지를 설치하려는 최종 사용자일 경우 아무 디렉터리에서나 수행할 수 있습니다.

 npm install "$package"

: 당신은 그냥 패키지를 사용하는 데 필요한 것을 얻을 수 있도록이 경우에는 일반적으로 개발 종속성을 원하지 않는 dependencies .

이 경우 개발 패키지를 설치하려는 경우 dev 구성 옵션을 true 설정할 수 있습니다. 가능하면 명령줄에서 다음과 같이 할 수 있습니다.

 npm install "$package" --dev

이 옵션은 훨씬 덜 일반적인 경우이므로 기본적으로 false

피어 종속성

(3.0 이전에 테스트됨)

출처: https://nodejs.org/en/blog/npm/peer-dependencies/

일반 종속성을 사용하면 여러 버전의 종속성을 가질 수 있습니다. 종속성 node_modules

예를 들어 dependency1 과 dependency2 모두 dependency3 에 의존하는 경우 프로젝트 트리는 다음과 같습니다.

 root/node_modules/ | +- dependency1/node_modules/ | | | +- dependency3 v1.0/ | | +- dependency2/node_modules/ | +- dependency3 v2.0/

그러나 플러그인은 일반적으로 이 컨텍스트 에서 호스트 라고 하는 다른 패키지가 필요하지 않은 패키지입니다. 대신에:

• 플러그인은 호스트에 필요합니다
• 플러그인은 호스트가 찾을 것으로 기대하는 표준 인터페이스를 제공합니다.
• 호스트만 사용자가 직접 호출하므로 단일 버전이 있어야 합니다.

예를 들어 dependency1 및 dependency2 피어가 dependency3 에 종속된 경우 프로젝트 트리는 다음과 같습니다.

 root/node_modules/ | +- dependency1/ | +- dependency2/ | +- dependency3 v1.0/

package.json 파일에서 dependency3 를 언급하지 않은 경우에도 발생합니다.

이것이 Inversion of Control 디자인 패턴의 한 예라고 생각합니다.

피어 종속성의 원형 예는 Grunt, 호스트 및 해당 플러그인입니다.

예를 들어 https://github.com/gruntjs/grunt-contrib-uglify 와 같은 Grunt 플러그인에서 다음을 볼 수 있습니다.

• grunt 는 peer-dependency
• 유일한 require('grunt') 는 tests/ : 실제로 프로그램에서 사용되지 않습니다.

사용자가 플러그인을 사용할 때 다음, 그는 암시에서 플러그인이 필요합니다 Gruntfile 추가하는 것으로 써 grunt.loadNpmTasks('grunt-contrib-uglify') 라인 만의 grunt 사용자가 직접 호출 할 것이다.

각 플러그인에 다른 Grunt 버전이 필요한 경우에는 작동하지 않습니다.

설명서

문서가 질문에 아주 잘 대답한다고 생각합니다. 아마도 노드/기타 패키지 관리자에 대해 충분히 익숙하지 않을 수 있습니다. Ruby 번들러에 대해 조금 알고 있기 때문에 아마 이해할 수 있을 것입니다.

핵심 라인은 다음과 같습니다.

이러한 것들은 패키지의 루트에서 npm link 또는 npm install을 수행할 때 설치되며 다른 npm 구성 매개변수처럼 관리할 수 있습니다. 주제에 대한 자세한 내용은 npm-config(7)를 참조하십시오.

그런 다음 npm-config(7) 아래에서 dev 찾습니다.

 Default: false Type: Boolean Install dev-dependencies along with packages.

Ciro Santilli 新疆再教育营六四事件法轮功郝海东

devDependencies를 설치하지 않으려면 npm install --production

Gayan Charith

예를 들어 mocha는 일반적으로 devDependency가 됩니다. 프로덕션에서는 테스트가 필요하지 않은 반면 express는 종속성이기 때문입니다.

Dan Kohn

의존성
코드에서 호출하는 함수를 제공하는 라이브러리와 같이 프로젝트를 실행해야 하는 종속성.
그것들은 전이적으로 설치됩니다(A가 B에 종속된 경우 C에 종속된 경우 A에 npm 설치는 B와 C를 설치합니다).
예: lodash: 프로젝트에서 일부 lodash 함수를 호출합니다.

devDependencies
코드를 가져와 자바스크립트, 테스트 프레임워크 또는 문서 생성기로 컴파일하는 컴파일러와 같이 개발 또는 릴리스 중에만 필요한 종속성.
그들은 전이적으로 설치되지 않습니다(A가 B에 의존하는 경우 dev-C에 의존하는 경우 A에 npm 설치는 B만 설치합니다).
예: grunt: 프로젝트는 자체 빌드를 위해 grunt를 사용합니다.

피어 종속성
프로젝트가 상위 프로젝트에서 연결하거나 수정하는 종속성으로, 일반적으로 다른 라이브러리 또는 도구에 대한 플러그인입니다. 상위 프로젝트(프로젝트에 종속될 프로젝트)가 연결하는 프로젝트에 종속성이 있는지 확인하기 위한 것입니다. 따라서 라이브러리 B에 기능을 추가하는 플러그인 C를 만드는 경우 프로젝트 A를 만드는 사람은 C에 대한 종속성이 있는 경우 B에 대한 종속성이 있어야 합니다.
설치되지 않고(npm < 3이 아닌 경우) 확인만 됩니다.
예: grunt: 프로젝트는 grunt에 기능을 추가하고 grunt를 사용하는 프로젝트에서만 사용할 수 있습니다.

이 문서는 피어 종속성을 정말 잘 설명합니다: https://nodejs.org/en/blog/npm/peer-dependencies/

또한 npm 문서는 시간이 지남에 따라 개선되었으며 이제 다양한 유형의 종속성에 대한 더 나은 설명이 있습니다. https://github.com/npm/cli/blob/latest/docs/content/configuring-npm/package-json .md#devdependencies

qwertzguy

패키지를 package.json 에 개발 종속성으로 저장하려면:

 npm install "$package" --save-dev

npm install 을 실행하면 devDependencies 와 dependencies 모두 설치됩니다. devDependencies 설치하지 않으려면 다음을 실행하십시오.

 npm install --production

Mohammed Safeer

프로덕션에서는 필요하지 않은 일부 모듈과 패키지는 개발에만 필요합니다. 문서 에서 말하는 것처럼 :

누군가가 자신의 프로그램에서 모듈을 다운로드하여 사용할 계획이라면 사용자가 사용하는 외부 테스트 또는 문서 프레임워크를 다운로드하고 빌드하는 것을 원하지 않거나 필요로 하지 않을 수 있습니다. 이 경우 이러한 추가 항목을 devDependencies 해시에 나열하는 것이 가장 좋습니다.

Amberlamps

나를 더 명확하게 만든 간단한 설명은 다음과 같습니다.

앱을 배포할 때 종속 항목의 모듈을 설치해야 합니다. 그렇지 않으면 앱이 작동하지 않습니다. devDependencies의 모듈은 해당 머신에서 개발하지 않기 때문에 프로덕션 서버에 설치할 필요가 없습니다. 링크

Jyoti Duhan

peerDependencies 는 위에서 언급한 Ciro 주제에 대한 블로그 게시물 에서 이 스니펫을 읽을 때까지 저에게 이해가 되지 않았습니다.

[ 플러그인 ]이 필요로 하는 것은 플러그인과 호스트 패키지 간의 이러한 "종속성"을 표현하는 방법입니다. "나는 내 호스트 패키지의 버전 1.2.x에 연결될 때만 작동하므로 나를 설치하는 경우 호환되는 호스트 옆에 있는지 확인하십시오." 이 관계를 피어 종속성이라고 합니다.

플러그인은 호스트의 특정 버전을 예상합니다...

peerDependencies 는 기능을 수행하기 위해 "호스트" 라이브러리가 필요한 라이브러리인 플러그인을 위한 것이지만 호스트의 최신 버전이 릴리스 되기 전에 작성되었을 수 있습니다.

즉, 내가 HostLibraryX v3 용 PluginX v1 HostLibraryX v4 (또는 심지어 HostLibraryX v3.0.1 )가 릴리스될 때 PluginX v1 이 작동한다는 보장이 없습니다.

...하지만 플러그인은 호스트에 의존하지 않습니다 ...

플러그인의 관점에서는 호스트 라이브러리에 기능 만 추가합니다. 플러그인에 종속성을 추가하기 위해 호스트가 "필요"하지 않으며 플러그인은 종종 말 그대로 호스트에 의존하지 않습니다. 호스트가 없으면 플러그인은 아무 것도 하지 않습니다.

이것은 dependencies 이 플러그인에 대한 올바른 개념이 아님을 의미합니다.

설상가상으로 내 호스트가 종속성으로 취급된다면 동일한 블로그 게시물이 언급 하는 이 상황에 처하게 될 것입니다(이 답변의 구성된 호스트 및 플러그인을 사용하기 위해 약간 편집됨).

그러나 이제 [HostLibraryX의 최신 버전을 PluginX에 대한 종속성으로 취급하는 경우] npm install 실행하면 예기치 않은 종속성 그래프가 나타납니다.

 ├── HostLibraryX@4.0.0 └─┬ PluginX@1.0.0 └── HostLibraryX@3.0.0

메인 애플리케이션과 다른 [HostLibraryX] API를 사용하는 플러그인에서 발생하는 미묘한 실패는 상상에 맡기겠습니다.

... 그리고 호스트는 분명히 플러그인에 의존하지 않습니다 ...

... 이것이 플러그인의 요점입니다. 이제 호스트가 모든 플러그인에 대한 종속성 정보를 포함할 수 있을 만큼 충분히 훌륭하다면 문제를 해결할 수 있지만 이는 또한 플러그인 관리 라는 거대한 새로운 문화적 문제를 야기할 것입니다!

플러그인의 요점은 익명으로 짝을 이룰 수 있다는 것입니다. 완벽한 세상에서 호스트가 모든 것을 관리하도록 하면 깔끔하고 단정할 수 있지만 우리는 도서관에서 고양이 무리를 요구하지 않을 것입니다.

우리가 계층적으로 의존적이지 않다면 아마도 우리는 내부의존적인 동료일 것입니다...

대신 우리는 동료라는 개념을 가지고 있습니다. 호스트도 플러그인도 상대방의 종속성 버킷에 있지 않습니다. 둘 다 종속성 그래프의 동일한 수준에 있습니다.

---

... 그러나 이것은 자동화 가능한 관계가 아닙니다. <<< 머니볼!!!

난 경우 PluginX v1 와의 피어를 기대 (즉,의 peerDependency가) HostLibraryX v3 , 나는 이렇게 말할 것이다. 당신이 최신으로 자동 업그레이드 한 경우 HostLibraryX v4 (버전 4 참고)과는 한 Plugin v1 설치하면 바로 알 필요가?

npm 은 나를 위해 이 상황을 관리할 수 없습니다 --

"이봐, 당신이 PluginX v1 HostLibraryX 를 v4에서 v3으로 자동으로 다운그레이드하는 중이야, kk?"

... 또는...

"이봐, 나는 당신이 PluginX v1 사용하고 있다는 것을 알았습니다. 그것은 당신이 마지막 업데이트 동안 먼지에 남겨둔 HostLibraryX v3 Plugin v1 !!1을 자동으로 제거하겠습니다!

아니 어때, npm?!

따라서 npm은 그렇지 않습니다. 상황을 HostLibraryX v4 Plugin v1 적합한 피어인지 파악할 수 있습니다.

---

코다

플러그인에서 좋은 peerDependency 관리는 이 개념이 실제로 더 직관적으로 작동하도록 합니다. 블로그 게시물에서 , 아직 다시...

한 가지 조언: 일반 종속성과 달리 피어 종속성 요구 사항은 관대해야 합니다. 피어 종속성을 특정 패치 버전으로 잠그면 안 됩니다. 하나의 Chai 플러그인이 Chai 1.4.1에 피어 의존하고 다른 플러그인이 Chai 1.5.0에 의존한다면 정말 짜증날 것입니다. 단순히 작성자가 게으르고 Chai의 실제 최소 버전을 알아내는 데 시간을 소비하지 않았기 때문입니다. 와 호환됩니다.

ruffin

이러한 종속성 설명에 대한 내 견해를 답변에 추가하고 싶습니다.

• dependencies 은 코드베이스, 일반적으로 프로덕션 코드에서 끝나는 항목 또는 코드 청크에서 직접 사용하는 데 사용됩니다.
• devDependencies 는 빌드 프로세스, 최종 코드가 어떻게 끝날지 관리하는 데 도움이 되는 도구, 타사 테스트 모듈(예: webpack 항목)에 사용됩니다.

Sîrbu Nicolae-Cezar

간단한 설명을 찾았습니다.

짧은 답변:

의존성 "...당신의 프로젝트가 실제로 프로덕션에서 작동할 수 있어야 하는 것들입니다."

devDependencies "...개발 중에 필요한 것입니다."

peerDependencies "종속성으로 사용할 수 있도록 자신의 라이브러리를 만들고 게시하려는 경우"

이 게시물의 자세한 내용: https://code-trotter.com/web/dependencies-vs-devdependencies-vs-peerdependencies

user739DamQ

요컨대

1. 종속성 - npm install <package> --save-prod 는 프로덕션 환경에서 애플리케이션에 필요한 패키지를 설치합니다.

2. DevDependencies - npm install <package> --save-dev 는 로컬 개발 및 테스트에만 필요한 패키지를 설치합니다.

3. npm install 입력하기만 하면 package.json에 언급된 모든 패키지가 설치됩니다.

따라서 로컬 컴퓨터에서 작업하는 경우 npm install 입력하고 계속하십시오. :)

cherankrish

종속성 대 개발 종속성

Dev 종속성은 개발 중에만 필요한 모듈인 반면 종속성은 런타임에 필요합니다. 애플리케이션을 배포하는 경우 종속성을 설치해야 합니다. 그렇지 않으면 앱이 작동하지 않습니다. 프로그램을 실행할 수 있도록 하는 코드에서 호출하는 라이브러리는 종속성으로 간주될 수 있습니다.

예- React , React-dom

개발 종속성 모듈은 해당 머신에서 개발하지 않을 것이기 때문에 프로덕션 서버에 설치할 필요가 없습니다. 코드를 자바스크립트로 변환하는 컴파일러 .컴파일러, 테스트 프레임워크 및 문서 생성기는 개발 중에만 필요하기 때문에 개발 종속성으로 간주될 수 있습니다.

예- ESLint , Babel , 웹팩

@참고로,

 mod-a dev-dependents: - mod-b dependents: - mod-c mod-d dev-dependents: - mod-e dependents: - mod-a ---- npm install mod-d installed modules: - mod-d - mod-a - mod-c ---- checkout the mod-d code repository npm install installed modules: - mod-a - mod-c - mod-e

npm에 게시하는 경우 올바른 모듈에 대해 올바른 플래그를 사용하는 것이 중요합니다. npm 모듈이 작동해야 하는 경우 "--save" 플래그를 사용하여 모듈을 종속성으로 저장합니다. 모듈이 작동할 필요는 없지만 테스트에 필요한 경우 "--save-dev" 플래그를 사용하십시오.

 # For dependent modulesnpm install dependent-module --save# For dev-dependent modules npm install development-module --save-dev

Selva Ganapathi

종속성

이것은 패키지를 실행하는 데 필요한 패키지이므로 사람들이 실행할 때 설치됩니다.

 npm install PACKAGE-NAME

프로젝트에서 jQuery를 사용한 경우를 예로 들 수 있습니다. 누군가 jQuery가 설치되어 있지 않으면 작동하지 않습니다. 종속성으로 저장하려면 다음을 사용하십시오.

 npm install --save

개발 종속성

이것들은 개발에서 사용하는 종속성이지만 사람들이 사용할 때는 필요하지 않으므로 사람들이 npm install 실행할 때 필요하지 않기 때문에 설치하지 않습니다. 예를 들어 mocha 를 사용하여 테스트하는 경우 사람들은 mocha 를 실행할 npm install 에서 mocha를 설치하지 않습니다. dev 종속성으로 저장하려면 다음을 사용하십시오.

 npm install PACKAGE --save-dev

피어 종속성

종속성으로 사용할 수 있도록 고유한 라이브러리를 만들고 게시하려는 경우 사용할 수 있습니다. 예를 들어, 패키지를 다른 프로젝트의 종속성으로 사용하려는 경우 다른 사람이 귀하의 프로젝트를 종속성으로 포함하는 프로젝트를 설치할 때 패키지도 설치됩니다. 대부분의 경우 피어 종속성을 사용하지 않습니다.

Quantalabs

npm 패키지를 배포하려고 할 때 dependencies 사용을 피해야 합니다. peerDependencies dependencies 에서 제거하는 것을 고려해야 합니다.

Melchia

출처 : http:www.stackoverflow.com/questions/18875674/whats-the-difference-between-dependencies-devdependencies-and-peerdependencies