당신의 ESLint 플러그인은 205개의 패키지를 설치합니다. 그중 69개는 ESLint입니다.
(dev.to)
ESLint 플러그인의 패키지 수가 많아 보이는 것은 ESLint 자체 의존성과 npm의 자동 설치 방식 때문이며, 실제 프로젝트의 의존성 무게를 정확히 파악하려면 중복 제거된 전체 트리를 측정해야 합니다.
이 글의 핵심 포인트
- 1ESLint 플러그인의 높은 패키지 수는 ESLint 자체의 기본 의존성(69개)을 포함한 결과임
- 2npm 7 이후 peerDependencies의 자동 설치로 인해 플러그인 설치 시 전체 린터가 카운트에 포함됨
- 3직접 의존성(direct dependencies)의 개수가 실제 설치되는 패키지 무게를 예측하는 정확한 지표가 아님
- 4여러 플러그인을 동시에 설치할 경우 npm의 중록 제거(deduping) 기능 덕분에 각 플러그지 개수의 단순 합보다 훨씬 적은 패키지가 설치됨
- 5패키지 수가 매우 적은 것은 유지보수가 중단된 상태를 의미할 수도 있으므로 주의가 필요함
이 글에 대한 공공지능 분석
왜 중요한가?
의존성 숫자의 착시 현상을 바로잡아 개발자가 불필요한 불안감을 갖지 않게 하며, 프로젝트의 경량화 정도를 판단할 때 잘못된 지표에 속지 않도록 정확한 측정 방법을 제시합니다.
어떤 배경과 맥락이 있나?
pm 7 이후 peerDependencies가 자동으로 설치되면서 ESLint와 같은 핵심 패키지가 모든 플러그인 카운트에 포함되게 되었고, 이는 의존성 트리가 실제보다 비대해 보이는 기술적 배경이 되었습니다.
업계에 어떤 영향을 주나?
개발팀이 라이브러리 선택 시 '패키지 개수'라는 왜곡된 지표에 매몰되지 않고, 실제 빌드 속도와 보안에 영향을 미치는 실질적인 의존성 무게와 유지보수 상태를 평가하는 문화를 정착시킬 수 있습니다.
한국 시장에 어떤 시사점이 있나?
빠른 배포와 효율적인 CI/CD 환경을 중시하는 한국 스타트업들에게, 잘못된 지표로 인한 불필요한 리팩토링 비용을 줄이고 정확한 기술 부채 측정 기준을 제공하여 개발 생산성을 높일 수 있습니다.
이 글에 대한 큐레이터 의견
많은 개발자가 '패키지 개수'를 프로젝트의 건강성이나 경량화의 척도로 삼지만, 이는 기술적으로 왜곡된 지표일 수 있습니다. 저자가 지적했듯, ESLint 자체의 기본 의존성이 포함된 숫자는 개발자에게 불필요한 경계심을 심어줄 수 있으며, 이는 오히려 실제 보안 취약점이나 의존성 폭발 문제를 간과하게 만들 위험이 있습니다.
물론, 패키지 수가 적은 것이 무조건 좋은 것은 아닙니다. 저자도 언급했듯, 패키지 수가 매우 적은 것은 업데이트가 멈춘(unmaintained) 상태를 의미할 수도 있기 때문입니다. 따라서 스타트업 창업자와 리드 개발자는 단순히 '가벼운' 패키지를 찾는 것을 넘어, 의존성 트리의 안정성과 업데이트 빈도, 그리고 실제 프로젝트에 추가되는 순수 무게를 종합적으로 판단하는 안목을 길러야 합니다.
관련 뉴스
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.