본문 바로가기
TIL

PeerDependency 에러 수정기

by 치우치지않는 2024. 9. 9.

인턴으로 근무한 회사 1일차, 내가 맡은 첫 임무는, 기존 분이 하고 계신 작업에서 일어난 배포 오류를 fix 하는 것이었다. 

처음에는 @types/react-helmet-async 이라는 라이브러리의 Helmet, HelmetProvider 컴포넌트에서 타입 에러가, @mui/x-date-pickers 라는 라이브러리에서 에러가 발생했고, 이 부분들을 해결하기 위해 각각 react 를 업그레이드하고, @mui/material 패키지를 추가로 설치했다. 그런데 여기서, @mui/material 패키지를 추가하자, 

PeerDependency 에러가 발생했다. 

PeerDependency..? Peer = 또래 Dependency = package.json 에 있는, 의존성을 관리하는 부분인가? 하는 생각이 들었고, 다행히 비슷한 뜻이었다. 

원래 Dependency 는 어떤 앱이 다른 앱을 사용한다의 의미라면, PeerDependency 는 일반 프로젝트에서는 잘 쓰이지 않고, 주로 라이브러리같은 곳에서 쓰이는 개념으로..

 

예를 들어 라이브러리가 아닌 일반적인 프로젝트에서 @mui/material 과 @mui/x-date-pickers 를 둘 다 쓰는 상황이라면, 우리는 이 둘을 각각 import 해서 쓴다. 그렇게 되면 앱 빌드 시에 이 라이브러리들의 코드가 앱에 포함되게 된다.

 

그런데 @mui/material  과 @mui/x-date-pickers  같은 라이브러리들에는, 자신의 코드뿐만 아니라 다른 코드가 앱에 포함되어 있을 수 있다. 예를 들어 두 라이브러리 모두 자신의 코드뿐만 아니라, framer-motion 을 사용하고 있다면, framer-motion 라이브러리의 코드를 각각 자신의 dependency 로 가지고 있을 것이다. 

 

이때 발생할 수 있는 문제가.. @mui/material과 @mui/x-date-pickers가 빌드될 때 둘이 따로 앱에 번들링된다는 점이다. 만약 앱도 framer motion 을 썼다면, 하나의 앱에 총 3개의 framer motion 이 들어가게 되고, 이는 필요하지 않은 코드가 번들링됨으로써 빌드 속도를 저하시키고 앱의 성능에도 영향을 끼칠 수 있게 된다. 

 

이러한 문제를 해결하기 위해 Peer Dependancy 라는 개념이 등장한다. 위에서 언급한 framer motion 을 다른 라이브러리에서 공유할 수 있다면? 똑같은 라이브러리를 여러 번 번들링하지 않아도 된다. 그리고 이를 표시하기 위해, 라이브러리는 자신의 peer dependancy 에 의존하는 라이브러리를 적어준다. 이는 자신이 해당 라이브러리를 직접 포함하지는 않고, 자신을 사용하는 쪽에서 그 라이브러리가 있으면, 그 라이브러리를 불러와서 쓴다는 의미이다. 

 

예를 들어 위 예제에서 @mui/material 에서 framer motion 을 peer dependancy 로 적었다면, @mui/material 는 framer motion 을 필요로 하지만, 자신이 직접 가지고 있지는 않고, 프로젝트에서 framer motion 을 찾아서 공유해서 쓰겠다는 의미인 것이다. 

 

그래서 어떤 라이브러리를 쓴다면, 그 라이브러리의 peer dependancy 를 보고 거기에 있는 라이브러리를 프로젝트의 dependancy에 넣어주어야 한다. 

 

그런데 이때.. (이제부터 내가 겪은 에러가 나온다.) 만약 peer dependancy 에 있는 라이브러리의 버전이 3 인데, 내 프로젝트의 dependancy 에 있는 라이브러리의 버전이 4라면 어떻게 될까..?

 

뜻하지 않은 에러가 발생할 확률이 아주 아주 높아지게 된다.

 

그래서 보통 peer dependancy 를 쓸 때는, 특정 버전을 명시하는 게 아니라, 사용 가능한 버전의 범위를 쓰게 된다. 이를 위해 보통 "^" 해당 기호를 쓰는데, 이 ^ 기호는 맨 앞 자리 수가 같으면서 자신 보다 높은 버전은 모두 허용한다는 의미이다. 예를 들어..

 

^1.3.4 로 되어있다면? 1.3.5 가능. 1.4.6 가능 이지만, 2.0.0 이나 1.3.2 는 안 된다!

 

이때 나의 경우 package.json 에 깔려 있던 @mui/material 의 버전이  ^6.0.1 이었고 @mui/x-date-picker 는 ^5.0.20 이었으며  node_modules/@mui/x-date-picker/package.json 의 peerDependancy 에 있는 @mui/material 은 ^5.4.1 이었다.

이 말인 즉슨, @mui/x-date-picker는 @mui/material 의 버전을 ^5.4.1 로 기대했는데, 실제 버전은 ^6.0.1 이어서, 버전이 맞지 않다고 앙탈을 부리고 있었던 것이다..!!

 

기존 프로젝트에서 (약 9개월간 방치된) 나는 타입 에러를 수정하기 위해 @mui/x-date-picker(이것도 아마 peer depencancy 였는데 누락되어서 에러를 뱉었던 게 아닐까) 를 다운 받았는데, 이때 버전이 @mui/material에서 요구하는 것과 맞지 않아, 이런 문제를 마주쳤다.. (현업에서만 마주칠 수 있는 문제인 것 같다. 사이드에서는 버전을 올릴 만큼 프로젝트가 오래 유지되기 힘들어서.. 덕분에 많이 배운 것 같아 감사하다!)

 

이 에러를 해결하기 위해 하루 종일 머리를 싸매며 끙끙 앓았던 기억이 있어, 혹시 다른 누군가도 나와 같은 에러를 만났을 때 도움을 주고자 글을 작성해 보았다. 

 

누군가에게 도움이 되었으면 좋겠다!

'TIL' 카테고리의 다른 글

2024.05.17 TIL  (1) 2024.05.17
2024.05.02 TIL 실패하더라도 나답게 살자.  (0) 2024.05.02
2024.05.01 TIL 나는~ 생각이~ 너무~나~ 많아~  (0) 2024.05.02
2024.04.01 TIL  (0) 2024.04.02
2024.03.29 TIL  (2) 2024.03.30

댓글