HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
🤎
프론트엔드 데브코스 5기 교육생
/
🦾
문동욱팀
/
🧭
1주차 논의
/
📦
패키지 매니저 결정
📦

패키지 매니저 결정

 
성민 설명
  • npm과 yarn은 유령의존성 문제가 있다.
    • 유령 의존성이란, 호이스팅 기법을 사용하는 npm, yarn의 고질적인 문제
    • 의존성을 설치하면, 이 의존성이 내부적으로 참조하고 있는 의존성이 있다.
    • 만일 여러가지 패키지에서 동일한 의존성을 참조하고 있다면 각 패키지별로 동일한 의존성을 설치해야 함
    • 결국 프로젝트 내의 node_modules 안에 똑같은 의존성이 2개 이상 설치될 수 있다는 것
    • 이는 메모리 낭비로 이어질 수 있음
    • 그래서 npm, yarn에서는 하위 의존성을 hoisting하는 시도를 했는데, 그렇게 함으로써 중복으로 의존성이 설치되는 문제는 해결할 수 있음
    • 하지만 프로젝트에서 실제로 설치하지 않은 의존성을 참조할 수 있는, 유령 의존성 문제가 발생함
  • pnpm은 이 문제를 심볼링 링크로 해결음
    • 의존성에 대한 의존성을 공용 캐시 저장소에 설치한 뒤, 해당 의존성을 참조하는 경우에는 이 의존성에 대한 링크로 참조하도록 함
    • 이를 통해 중복 의존성 설치로 인한 메모리 낭비 문제를 해결할 수 있고, 이에 더해 의존성 설치에 발생하는 시간 비용 절감 효과도 챙길 수 있음
 
성민 경험
  • 프로젝트에서 특정 모듈을 import 하기 위해 자동완성 기능을 이용했는데, 내가 직접 설치한 적 없는 패키지가 떴다.
    • 예를 들어, styled-component에서 emotion을 의존성으로 갖고 있고, 나는 프로젝트에서 styled-component만을 설치했다고 가정해보자.
    • 두 라이브러리는 모두 styled라는 함수를 사용하는데, 프로젝트 자동완성으로 styled-component와 emotion의 styled 함수를 모두 사용할 수 있게 된 것이다.
    • 프로젝트에서는 styled-component만을 설치했기 때문에 굉장히 당황했던 기억이 있다.
  • 결국, 의도하지 않은 결과가 발생할 수 있기 때문에 불확실성 통제를 위해 고려해보면 좋을 것 같다.
    •