Javascript 개발자로서 우리 모두는 프로젝트에서 종속성과 devDependency라는 두 가지 서로 다른 종속성을 알고 있습니다. 하지만 PeerDependency는 어떻습니까?

이 시리즈에서는 Javascript에서 덜 일반적인 종속성을 살펴보겠습니다. 그것이 무엇인지, 도서관 이용자로서 내가 알아야 할 것은 무엇인지, 도서관 저자를 위한 모범 사례는 무엇인지 연구하겠습니다.

NPM의 종속성이란 무엇입니까?

다양한 일반적인 유형을 요약해 보겠습니다.

• 종속성: 애플리케이션에 사용되는 도구입니다. 좋은 예는 반응, 각도 및 표현입니다. 애플리케이션이 프로덕션 단계에 있을 때 종속성에 대한 라이브러리 코드가 내부적으로 실행되어 애플리케이션에 전원을 공급합니다.

• devDependency: 이러한 유틸리티를 사용하여 애플리케이션을 구축합니다. 여기서는 코드를 컴파일하거나 구문 분석하기 위한 라이브러리와 테스트를 실행하기 위한 라이브러리를 찾을 수 있습니다.

PeerDependency란 무엇입니까?

작성자는 모든 것이 예상대로 작동하도록 작업공간/프로젝트에 설치해야 하는 경우 특정 라이브러리를 PeerDependency로 지정합니다. 이는 NPM(및 라이브러리를 설치하는 개발자)에게 패키지가 올바르게 작동하려면 다른 패키지의 특정 버전(또는 버전 범위)이 필요함을 알려줍니다. 하지만 사용자는 해당 종속성을 설치하고 관리할 책임이 있습니다.

예를 들어보겠습니다. 라이브러리가 실행될 환경에 설치해야 하는 즐겨찾는 프레임워크용 유틸리티를 만들고 있습니다. 이 시나리오를 정확하게 지정하는 방법은 NPM PeerDependency 기능을 사용하는 것입니다. 이는 라이브러리의 원활한 통합을 위한 명확한 지침을 제공합니다.

이러한 관행은 적절한 기능을 위한 작업공간 요구 사항을 나타내야 하기 때문에 "플러그인"으로 작동하는 라이브러리에서 특히 일반적입니다.

PeerDependency의 실제 예

인기 있는 React 라이브러리인 React-datepicker를 분석해 보겠습니다. 현재 package.json이 어떻게 보이는지 살펴보면 반응 날짜 선택기가 올바르게 작동하려면 최소한 React 버전 ^16.9.0이 필요하다는 것을 알 수 있습니다.

"peerDependencies": {
  "react": "^16.9.0 || ^17 || ^18",
  "react-dom": "^16.9.0 || ^17 || ^18"
},

이 요구 사항을 준수하지 않으면 예상치 못한 동작이 발생할 수 있습니다.

PeerDependency 주소의 과제

버전 충돌은 프로젝트의 패키지가 동일한 라이브러리의 다른 버전에 의존할 때 발생합니다. 이로 인해 특히 상태 관리 및 구성 요소 통신에 동일한 인스턴스를 공유하는 것이 중요한 React와 같은 라이브러리의 경우 오류가 발생할 수 있습니다. PeerDependency가 없으면 여러 라이브러리 버전이 설치되어 예기치 않은 동작이 발생할 수 있습니다.

이러한 문제를 방지하기 위해 PeerDependency를 사용하면 패키지 작성자가 패키지를 직접 설치하지 않고도 패키지에 필요한 종속성 버전을 지정할 수 있습니다. 이렇게 하면 패키지를 사용하는 개발자에게 책임이 이전되어 호환 가능한 단일 종속성 버전을 설치하게 됩니다. 예를 들어, 반응 날짜 선택기(react-datepicker) 및 반응 라우터(react-router)와 같은 라이브러리는 프로젝트에서 동일한 버전의 React와 원활하게 작동하도록 PeerDependency를 사용합니다.

또 다른 예

이 시나리오를 상상해 보세요. rxjs에 대한 멋진 연산자를 공유하기 위해 라이브러리를 만들고 있습니다. rxjs를 PeerDependency 대신 종속성으로 설정하면 라이브러리는 자체 버전의 rxjs를 설치합니다. 처음에는 별 문제가 아닌 것처럼 보이지만 실제로는 버전 충돌이 발생할 수 있습니다.

라이브러리를 설치하는 프로젝트가 이미 다른 버전의 rxjs를 사용하는 경우 심각한 문제가 발생할 수 있습니다. 애플리케이션은 두 개의 rxjs 인스턴스(라이브러리에서 하나, 프로젝트 자체에서 하나)로 끝날 수 있습니다. rxjs는 공유된 관찰 가능 항목 및 구독에 크게 의존하기 때문에 두 버전을 동시에 실행하면 스트림이 제대로 동기화되지 않거나 이벤트가 누락되는 등 예측할 수 없는 동작이 발생할 수 있습니다.

peerDependency를 대신 사용하면 이 문제를 피할 수 있습니다. 패키지는 rxjs의 특정 버전(또는 범위)이 있을 것으로 예상하지만 자체 버전을 설치하지는 않는다는 신호를 프로젝트에 보냅니다. 이런 방식으로 프로젝트는 라이브러리와 코드베이스의 다른 부분에서 공유되는 단일 버전의 rxjs를 사용하여 모든 것이 원활하고 조화롭게 실행되도록 합니다.

결론

peerDependency는 종속성 또는 devDependency만큼 일반적으로 논의되지 않을 수 있지만 복잡한 프로젝트에서 호환성을 보장하고 버전 충돌을 피하는 데 중요한 역할을 합니다. 라이브러리를 직접 설치하지 않고도 라이브러리에 필요한 공유 종속성 버전을 명확하게 정의함으로써 피어Dependency를 사용하면 개발자가 프로젝트 환경에 대한 제어를 유지할 수 있습니다.

이 첫 번째 게시물의 목표는 PeerDependency에 대한 좋은 이해 기반을 만드는 것입니다. 이 시리즈의 다음 장에서는 PeerDependency가 있는 라이브러리 사용자로서 PeerDependency의 다양한 측면, 일반적인 문제를 극복하는 방법, 다양한 Javascript 패키지 관리자에서 작동하는 방식을 보다 실용적인 방법으로 살펴보겠습니다.