[Javascript] dependencies와 devDependencies 차이점 정리

안녕하세요. 성조입니다.

 

이번 포스팅은 dependencies(종속성)와 devDependencies(개발 종속성)의 차이점에 대해서 정리해 보려합니다.

100% 완벽한 정답이 아닐 수 있으므로 학습 또는 참고용으로 봐주시면 감사드립니다.

또한 혹시나 잘못된 정보 전달이 있는 경우 언제든지 댓글 달아서 피드백 주시면 감사드리겠습니다.

 

---

dependencies와 devDependencies는 프로젝트의 종속성을 관리하기 위해서 나눠진 카테고리이다.

위 카테고리는 javascript 및 node.js 프로젝트에서 package.json 파일을 통하여 관리되며, 관련된 사항은 다음과 같다.

 

 

 

dependencies와 devDependencies의 차이점

결론

- dependencies는 프로젝트를 실행하는데 필요한 패키지를 포함한다.

- devDependencies는 개발 과정에서 필요한 도구와 관련된 패키지를 포함한다.

 

 

dependencies

dependencies는 프로덕션 환경(실제로 최종 배포됐을 때. 개발자가 의도한 용도로 사용자들이 사용하는 환경을 의미한다.)에 필요한 라이브러리, 프레임워크 등을 포함한다.

예로 들면 웹 서버 프레임워크인 Express.js 패키지가 dependencies에 속할 수 있다.

 

조금 더 예를 들면 다음과 같이 다양한 라이브러리와 프레임워크가 배포 시 필요하므로 dependencies에 존재한다.

웹 프레임워크 : express, koa, hapi, nest.js, etc...

데이터베이스 라이브러리 : mysql, mongoose, sequelize, knex, etc...

유틸리티 라이브러리 : lodash, moment, axios, etc...

 

 

 

 

devDependencies

devDependencies는 개발 및 테스트에서 필요한 패키지를 포함하는 곳을 의미한다.

단어 그대로 이해하면 dev(개발)Dependencies(종속성) 개발에 필요한 종속성이 된다.

일반적으로 이 종속성의 위치에는 빌드 도구, 테스트 라이브러리, 코드 스타일 검사기 등등이 존재할 수 있으며, 배포와 무관한 파일을 이 devDependencies 종속성 패키지에 추가한다.

 

다음과 같은 빌드 도구, 프레임워크, 스타일 컨벤션을 위한 검사기 등이 존재한다.

빌드 도구 : webpack, gulp, rollup, etc...

테스트 프레임워크 : jest(js에서 많이 사용되는 프레임워크이다.), mocha, jasmine, etc...

코드 컨벤션을 위한 스타일 검사기 : eslint, prettier, stylelint, etc...

코드 변환 도구 : bable, typescript(타입을 지정하여 오류를 줄이는데 활용되며 모던 자바스크립트 시대에서는 거의 기본적으로 활용된다.)

 

 

 

 

dependencies와 devDependencies를 구분 시 긍정적 측면

1. 배포 및 개발 환경의 분리.

각각 배포 환경과 개발 환경의 종속성(의존성)을 구분하면 핵심 기능에 맞춰서 각 환경에 맞는 종속성을 분리할 수 있는 장점이 존재한다.

 

 

2. 애플리케이션 최적화

올바른 위치에서 종속성(의존성)이 중복 설치되지 않도록 관리하여 프로젝트의 패키지를 최적화할 수 있게 된다.

 

 

3. 코드 리뷰 및 구조 이해와 관리

종속성 버전이 올바르게 설치되어 있고, 추가적으로 찾아서 정리할 필요가 없어진다면. 개발자들끼리 어떤 위치에 존재하는지 조금 더 수월하게 소통할 수 있으며, 프로젝트 구조가 명확하게 이해하고 있을 때. 개발 생산성과 품질을 높히기 조금 더 수월해질 수 있다. 서로 관리하고 있는 패키지를 기준으로 코드를 조금 더 수월하게 리뷰할 수 있다.

 

 

4. 종속성(의존성 관리) 버전 업데이트 및 변경

Node 버전에 따라서 라이브러리, 프레임워크들이 지원하는 종속성 버전이 모두 다르다. 다른 버전들이 섞이지 않고, 정리됐다면 올바르게 배포와 개발에 맞춰서 버전을 관리할 수 있는 장점이 있다.

 

라이브러리와 프레임워크의 경우 버전이 호환되지 않는 경우가 발생하면 전체 프로그램에 큰 버그가 발생할 수 있는 치명적 문제 발생할 수 있으므로 주의하여 구분하는 것과 올바른 버전 마이그레이션을 통해서 문제를 최소화 하는 것이 좋다.

 

어떤 버전에서는 A 라이브러리가 지원되는데 마이그레이션 했을 때. A 라이브러리가 지원하지 않는 경우도 존재하기 때문이다. 이런 경우 대체된 라이브러리가 존재하거나 호환이 맞지 않는 경우가 존재하므로 직접 구현하거나, 대체제를 찾아야한다. 만약 종속성이 중복 설치되거나, 뒤죽박죽 설치된 경우 문제가 커질 수 있음을 주의하자.

 

 

5. 프로젝트 문서화

프로젝트 참여하는 개발자들이 배포에 있는 것과 개발에 있는 종속성(의존성)을 서로 공유할 때 빠르게 활용될 수 있으며, 개발 문서를 작성할 때도 어떻게 구분됐는지 정리하고 보기 편하게 다룰 수 있게 된다.

 

 

 

---

위에 언급드린 것처럼 올바른 지식 전달이 아니라면 언제든지 댓글 부탁드리며, 궁금한 사항이 있어도 댓글 주시면 답변드리겠습니다.

 

향후 포스팅에서 종속성 === 의존성 동일한 표현인데 개발용 패키지와 배포용 패키지의 의존성에 맞는 설치 방법을 정리하려고 합니다.

 

감사드립니다. 다음 포스팅 때 뵙겠습니다.