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


2027

이 문서는 내 질문에 매우 잘못 대답합니다. 나는 그 설명을 이해하지 못했습니다. 누군가 더 간단한 말로 말할 수 있습니까? 간단한 단어를 선택하기 어려운 경우를 예로들 수 있습니다.

EDIT 도 추가되었습니다 peerDependencies.이 기능은 밀접하게 관련되어 있으며 혼동을 일으킬 수 있습니다.


48
또한 거기에 있습니다 optionalDependencies지금.
Aidan Feldman 2016 년

118
@AidanFeldman "optionalDependencies"는 오늘의 나의 옥시 모론입니다
Nick Bull

1
npm 설명서에는 "종속성": 프로덕션 환경에서 응용 프로그램에 필요한 패키지가 있습니다. "devDependencies": 로컬 개발 및 테스트에만 필요한 패키지. 링크 참조 : docs.npmjs.com/…
Deke

답변:


2362

중요한 행동 차이 요약 :

  • dependencies 둘 다에 설치됩니다 :

    • npm install 포함 된 디렉토리에서 package.json
    • npm install $package 다른 디렉토리에
  • devDependencies 아르:

    • 또한 플래그 를 전달하지 않는 한 ( 가얀 카리스의 대답을 찬성하지 마십시오 ) npm install를 포함하는 디렉토리에 설치했습니다 .package.json--production
    • 옵션을 지정 npm install "$package"하지 않으면 다른 디렉토리에 설치되지 않습니다 --dev.
    • 전 이적으로 설치되지 않았습니다.
  • peerDependencies:

    • 3.0 이전 : 누락 된 경우 항상 설치되며, 호환되지 않는 여러 버전의 종속성이 다른 종속성에 의해 사용되는 경우 오류가 발생합니다.
    • 3.0에서 시작될 것으로 예상 됨 (예상치 않음) :에서 누락 된 경우 경고를 표시 npm install하고 직접 종속성을 해결해야합니다. 실행시 종속성이 없으면 오류가 발생합니다 ( @nextgentech에 의해 언급 )
  • 과도 성 ( Ben Hutchison ) :

    • dependencies A가 B를 요구하고 B가 C를 요구하면 C가 설치되고, 그렇지 않으면 B가 작동하지 않으며 A도 B가 작동하지 않습니다.

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

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

devDependencies

dependenciesdevDependencies단위 테스트, CoffeeScript에서 JavaScript 로의 변환, 축소 등을 개발하기 위해서만 실행해야합니다 .

패키지를 개발하려면 패키지를 다운로드하고 (예 :를 통해 git clone) 루트가있는 루트로 이동하여 package.json다음을 실행하십시오.

npm install

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

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

npm install "$package"

이 경우 일반적으로 개발 종속성을 원하지 않으므로 패키지 사용에 필요한 것을 얻는 것입니다 dependencies.

이 경우 개발 패키지를 실제로 설치하려면 명령 행에서 다음과 같이 dev구성 옵션을로 설정하십시오 true.

npm install "$package" --dev

이 옵션은 false기본적으로 훨씬 덜 일반적인 경우이므로 기본적으로 사용됩니다.

peerDependencies

(3.0 이전에 테스트)

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

정기적 인 종속성을 사용하면 여러 버전의 종속성을 가질 수 있습니다. 종속성의 내부에 간단히 설치됩니다 node_modules.

예 경우 dependency1dependency2모두에 의존 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/

당신이 언급 적이 있지만이 경우에도 발생 dependency3당신의 package.json파일.

이것이 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 링크 또는 npm 설치를 수행 할 때 설치되며 다른 npm 구성 매개 변수처럼 관리 할 수 ​​있습니다. 주제에 대한 자세한 내용은 npm-config (7)를 참조하십시오.

그런 다음 npm-config (7)에서 다음을 찾으십시오 dev.

Default: false
Type: Boolean

Install dev-dependencies along with packages.

5
아 나는 내가 오해 한 것을 본다. 당신의 대답은 npm install package내가 생각하는 것보다 '종속성'[패키지]라는 패키지를 설치하는 것 '이 아니라 개발 의존성이 아닌 모든 패키지를 설치하는 데 사용하는 명령 인 것처럼 읽습니다 . 이것을 읽기 전에. 내가 당신이라면 [package-name]이라고 말하여 당신이 의미하는 것이 'insert-name-here'라는 것을 분명히 보여줍니다.
Tom W

184
대단해! 나는 결코 깨닫지 못했지만이 대답은 npm 패키지를 게시 할 때만 종속성 대 devDependencies 차이가 적용 가능하다는 것을 가르쳐주었습니다. 응용 프로그램이나 사이트에서 작업하는 경우 그다지 중요하지 않습니다. 감사!
jedd.ahyoung

3
이 게시물은 peerDependencies다가오는 npm @ 3 의 변경된 동작 을 반영하도록 업데이트되어야합니다 . 에서 blog.npmjs.org/post/110924823920/npm-weekly-5 :. 피어 의존성이 아직 설치되지 않은 경우 우리는 자동으로 더 이상 피어 의존성을 다운로드하지 않습니다 "대신에, 우리는 당신을 경고하는 것이 당신을 필요로합니다. peerDependency 충돌을 수동으로 직접 해결할 수는 있지만 장기적으로는 패키지 종속성으로 인해 까다로울 가능성이 낮아집니다. "
nextgentech

8
또한 종속 패키지는 devDependencies를 전 이적으로 설치하지 않습니다. 예 : 패키지 A는 패키지 B에 의존합니다. 패키지 B는 패키지 C에 의존하고 B도 패키지 D에 의존합니다. npm install패키지 A에서 실행 하면 B가 아니라 C를 받게됩니다.
Ben Hutchison

9
로 설정하면 devDependencies설치되지 않은 것을 언급하는 것이 중요 NODE_ENV합니다 production.
Augusto Franzoia

490

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


1
npm install --save는 소프트웨어 종속성을위한 것입니까?
Vamsi Pavan Mahesh

19
npm install은 모든 종속성을 설치합니다. --save 플래그는 package.json에 특정 모듈을 추가 할 때 사용됩니다. 예 : npm install uglify --save는 프로젝트 폴더에 uglify를 설치하고 프로젝트, package.json 파일에 uglify를 추가합니다.
Gayan Charith

6
우리는 devDependencies와 대화하고 있기 때문에 --save-dev를 사용하여 새로운 모듈을 devDependency로 저장할 수 있습니다. 예 : npm install uglify --save-dev
Mykaelos

9
npm 5부터는 --save옵션이 더 이상 필요하지 않습니다. "npm install my-package"를 수행하면 package.json파일 의 종속성으로 my-package가 추가 됩니다.
Martin Carel

그냥 npm 설치
sultan aslam

116

예를 들어, 모카는 일반적으로 devDependency가 될 것입니다. 프로덕션에서는 테스트가 필요하지 않지만 Express는 종속성입니다.


4
프로덕션 서버 시작하기 전에 자체 테스트를 수행 할 수 있기 때문에 나는 종속성으로 테스트를 넣어 향하다 것

47
대신 테스트를 실행 한 다음 프로덕션에 배포하는 Hudson 또는 CircleCI와 같은 지속적인 통합 서비스를 사용하는 것이 좋습니다.
Dan Kohn

1
CI 서버가 prod 서버와 다를 수 있기 때문에 실제 서버를 테스트하는 것이 여전히 관련이있을 수 있으며,이 차이로 인해 앱이 시작되지 않을 수 있습니다.
Nicole

2
@Nicole 왜 스테이징 서버를 제품 구성과 동일하지 않게 하시겠습니까?
Lucas

1
그런 다음 테스트 종속성을 일반 종속성으로 추가하면 추가 라이브러리가 많이 생겨서 각 라이브러리가 어떤 방식 으로든 실패 할 수 있습니다. 가능한 한 적은 코드로 가벼운 프로덕션 서버를 향해 기울였습니다. 가장 좋은 코드는 코드가 없다는 것을 기억하십시오!
Stijn de Witt

69

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

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

peerDependencies
프로젝트가 상위 프로젝트에서 다른 라이브러리 또는 도구의 플러그인에 연결하거나 수정하는 종속성. 부모 프로젝트 (프로젝트에 의존 할 프로젝트)가 연결하는 프로젝트에 종속되어 있는지 확인하기위한 것입니다. 따라서 라이브러리 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/doc/files/package.json.md#devdependencies


63

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

npm install "$package" --save-dev

당신이 실행하면 npm install그것은 모두 설치됩니다 devDependencies하고 dependencies. 설치 devDependencies실행 을 피하려면 다음을 수행하십시오.

npm install --production

3
당신은 또한 사용할 수 있습니다 : npm i -S
Maysara Alhindi

36

개발에는 필요하지 않은 일부 모듈 및 패키지가 있으며 프로덕션에는 필요하지 않습니다. 설명서 에 나와있는 것처럼 :

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


프로덕션에서 bundle.js 파일 만 실행하면 어떻게 되나요? 그 의존성이 정말로 필요합니까?
RegarBoy

서버에서 bundle.js를 실행하는 경우 서버 측 웹팩 또는 기타 작업을 수행하는 중입니다 ... 일반적으로 그렇지 않고 실제로 제대로 실행되도록하려면 많은 작업이 필요합니다 (I 내가 그렇게했기 때문에 알고). bundle.js가 브라우저에 제공되고 클라이언트 측 코드가 포함되어 있다고 생각합니다.
Stijn de Witt

16

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

앱을 배포 할 때 종속성이있는 모듈을 설치해야합니다. 그렇지 않으면 앱이 작동하지 않습니다. 해당 시스템에서 개발하지 않으므로 devDependencies의 모듈을 프로덕션 서버에 설치할 필요가 없습니다. 링크


2
따라서 웹 사이트를 만들거나 prod 버전으로 모든 libs가 inlined 될 vendor.js경우 컴파일 된 코드가 저장소에 커밋되면 모든 dep가 dev dep이어야합니까? 그것은 이상한 otherwice로 그리고 ... 당신이 모듈을 컴파일뿐만 아니라 설치 (테스트 회귀로 이어질 수있는 서브 모듈의 변경 사항으로 여기 어딘가에도)을 가지고, 최선을 다하고해야한다
Qwertiy

멋진 답변이지만 질문이 있습니까? 가능한 Webpack이 손상된 번들을 빌드합니까? 내 생각에 devDependencies 패키지는 제품 버전에서 작동하지 않습니다 webpack -p. 내 질문에 대답하십시오.
AmerllicA

프로덕션 빌드 중에 문제가있는 경우 배포 프로세스는 빌드시 오류를 표시하고 손상된 코드를 프로덕션으로 푸시하지 않는 방식으로 설계해야합니다 (예 : Jenkins를 시도 할 수 있음). 어쨌든 프로덕션 서버에는 Devdependencies를 설치할 필요가 없습니다.
Jyoti Duhan

그리고 피어 종속성은 어떻습니까?
dev27

13

이러한 의존성 설명에 대한 나의 견해에 대한 답변을 추가하고 싶습니다.

  • dependencies 코드베이스에서 직접 사용하거나 일반적으로 프로덕션 코드로 끝나는 것 또는 코드 덩어리에 사용됩니다.
  • devDependencies 빌드 프로세스, 엔드 코드의 종료 방식을 관리하는 데 도움이되는 도구, 타사 테스트 모듈 (예 : 웹팩)에 사용됩니다.

CSS 자산은 어떻습니까?
Brian Zelip

8

한마디로

  1. 종속성 - npm install <package> --save-prod프로덕션 환경에서 응용 프로그램에 필요한 패키지를 설치합니다.

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

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

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


6

peerDependencies위에서 언급 한 Ciro 주제에 대한 블로그 게시물 에서이 스 니펫을 읽을 때까지는 나에게 의미가 없었습니다 .

무엇 [ 플러그인 ] 필요하면 플러그인과 자신의 호스트 패키지 사이의 이러한 "의존성"을 표현하는 방법입니다. "호스트 패키지의 1.2.x 버전에 연결했을 때만 작동하므로 설치하는 경우 호환되는 호스트와 함께 있는지 확인하십시오." 우리는이 관계를 동료 의존성이라고 부릅니다.

플러그인은 특정 버전의 호스트를 기대 합니다 ...

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

그건 내가 쓰는 경우입니다 PluginX v1위해 HostLibraryX v3멀리 걸어이 보장의 PluginX v1경우 작동하지 않습니다 HostLibraryX v4(또는HostLibraryX v3.0.1 해제).

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

플러그인의 관점 에서 호스트 라이브러리 에만 기능을 추가 합니다. 플러그인에 의존성을 추가하기 위해 호스트에 실제로 "필요"하지는 않으며 플러그인은 종종 호스트에 의존 하지 않습니다 . 호스트가 없으면 플러그인은 아무런 영향을 미치지 않습니다.

이것은 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! 나는 HostLibraryXv4에서 v3, kk로 자동 다운 그레이드 하고 있습니까?"

... 또는 ...

"이봐 요, 당신이 사용 PluginX v1하고 HostLibraryX v3있는 것을 보았습니다. 마지막 업데이트 중에 먼지가 남았을 것으로 예상 됩니다. 안전을 위해 자동으로 !! 1을 제거하고 있습니다 Plugin v1!

안돼, npm ?!

그래서 npm은 그렇지 않습니다. 상황을 HostLibraryX v4알려주고에 적합한 피어 인지 파악할 수 있습니다 Plugin v1.


코다

peerDependency플러그인을 잘 관리하면이 개념이 실제로보다 직관적으로 작동합니다. 에서 블로그 게시물 , 다시 한번 ...

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


4

의존성 vs 개발자 의존성

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

예 : 반응, 반응

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

예 : ESLint, Babel, 웹팩

@FYI,

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 modules
npm install dependent-module --save

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

1

npm 패키지를 배포 할 때는를 사용하지 않아야합니다 dependencies. 대신에 추가 peerDependencies또는 제거 를 고려해야 합니다 dependencies.


1

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

짧은 답변:

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

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

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

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.