NPM

[beecomci]

FE 개발에 Node.js가 필요한 이유?

• JS 스펙의 빠른 발전에 비해 브라우저의 지원 속도는 항상 뒤쳐짐
• 아무리 편리한 스펙이 나와도 이것을 구현해 줄 수 있는 징검다리 역할인 바벨 같은 도구를 사용해야 적용 가능
• 웹펙, NPM 같은 노드 기술로 만들어진 환경에서 사용할 때 비로소 제대로 자동화된 FE 개발 환경을 만들 수 있음

LTS 버전 ?

• LTS : Long Term Support
• 일반적인 경우보다 장기간에 걸쳐 지원하도록 특별히 만들어진 SW 버전
• 보통 짝수 버전이 LTS 버전이며 안정적이고 신뢰도가 높고, 불안정할 수 있지만 최신 기능을 지원하는 것이 홀수 버전
• 서버에는 LTS 버전이 사용되고, 개발환경 구축에 사용할 때는 홀수 버전인 최신 버전을 사용

NPM

• 개발 프로젝트는 외부 라이브러리를 다운로드 받고 빌드 하는 등의 일련의 명령어를 자동화해서 프로젝트를 관리하는 도구가 존재
• NPM은 JS 기반의 프로젝트 빌드 도구인 셈
• package.json에 등록한 scripts를 이용해서 프로젝트를 실행
• 빌드, 테스트, 배포, 실행 등의 명령어를 등록 후 npm 명령어로 실행

기본적으로 가진 npm 명령어 이외에 커스텀으로 추가한 명령어는 `run`을 추가해서 실행

$ npm run build
$ npm run lint

이외의 참고 명령어

$ npm view ${모듈명} versions // 모듈의 전체 버전 확인
$ cat node_modules/${모듈명}/package.json // 모듈의 설치된 버전 확인

패키지 설치 방식

광고 업무를 하면서 어떤 프로젝트는 CDN을 사용하거나 아니면 직접 모듈 파일을 다운로드해서 넣거나, NPM을 사용해서 의존성을 관리하는 경우가 있어서 이 차이가 궁금해 서치해봄 !

CDN

• 대부분 템플릿에서 사용 중인 웹 플레이어 같은 경우는 모두 동영상 인프라팀에서 제공하는 배포 URL을 가져다가 사용함
• (정확히 말하면 cdn 방식으로 호출해서 그대로 사용하는 정석인? 방법은 아니지만 의미는 동일 !)

<script src="https://unpkg.com/react@16/umd/react.development.js"></script>

• CDN(Contents Delivery Network)으로 제공하는 라이브러리를 직접 가져오는 방식
• CDN 서버 장애로 인해 외부 라이브러리를 못가져오게 된다면, 우리 앱 서버가 정상이더라도 앱이 정상적으로 동작하지 않을 것

직접 다운로드

• 이 방식은 휴먼 에러를 발생시킬 수 있음
• 라이브러리는 계속 업데이트 될 것이고 최신 버전이 필요할 때, 매번 직접 다운로드하는 것은 귀찮은 일
• 버전에 따라 하위 호환성 여부까지 확인하려면 실수가 생길 수 있음
• 그렇다면 라이브러리를 한 곳에서 업데이트하고 하위 호환되는 안전한 버전만 다운받아 사용할 수 있다면?

NPM

• NPM을 사용해서 모듈 의존성을 관리
• npm install 명령어로 외부 패키지를 프로젝트 폴더에 다운로드
  • package.json에 설치한 패키지 정보가 기록됨
  • 빌드 후, 프로젝트 번들 js 파일에 패키지가 포함되어 빌드된 상태로 갖고 있는 것

"dependencies": {
    "@egjs/flicking": "^2.5.0"
}

(~)틸트 or (^)캐럿

• 버전 번호를 관리하기 위한 규칙이 필요한데, 이 체계를 유의적 버전이라고 함
• NPM은 유의적 버전을 따르는 전제 아래 패키지 버전을 관리함
• 유의적 버전은 Major, Minor, Patch 3가지 숫자를 조합해서 버전 관리
• 예) 16.12.3 : 주 버전이 16, 부 버전이 12, 수 버전이 3
  • 주 버전(Major) : 기존 버전과 호환되지 않게 변경한 경우
  • 부 버전(Minor) : 기존 버전과 호환되면서 기능이 추가된 경우
  • 수 버전(Patch) : 기존 버전과 호환되면서 버그를 수정한 경우

(~)틸트 방식

• 마이너 버전이 명시되어 있으면 패치 버전만 변경
• ~1.2.3 표기는 1.2.3부터 1.3.0 미만까지 포함
• 하지만 마이너 버전이 없으면 마이너 버전을 갱신
  • 보통 라이브러리 정식 릴리즈 전에는 마이너 버전이 변하더라도 하위 호환성을 지키지 못하고 배포하는 경우가 빈번
  • 그래서 틸트 방식은 하위 호환성을 지키지 못하는 마이너 버전으로 갱신되어 버릴 수 있는 문제 발생 가능 !!

(^)캐럿 방식

• 정식 버전에서 마이너와 패치 버전을 변경함
• ^1.2.3 표기는 1.2.3부터 2.0.0 미만까지 포함
• 정식 버전 미만인 0.x 버전은 패치만 갱신
  • ^0 표기는 0.0.0부터 0.1.0 미만까지 포함