프론트엔드에서의 NodeJS와 NPM

프론트엔드에서 왜 Node.js가?

개발 환경을 이해하고, 구성하는데 NodeJS는 중요합니다. 왜일까요?

이를 알기 전에 Node.js가 무엇인지 알아야겠네요. 이를 알기 위해서는 공식 문서를 확인해봅시다.

Node.js®는 Chrome V8 JavaScript 엔진으로 빌드된 JavaScript 런타임입니다.

JavaScript는 스크립트 언어이기 때문에, 이를 해석해줄 환경이 별도로 필요합니다. 주로 사용해왔던 실행 환경은 바로 브라우저의 개발자 콘솔입니다. 브라우저 외부에서는 js를 사용할 수 없었습니다. 즉, 기존 javascript 개발 환경은 브라우저에 종속적이었던 것이죠. node.js와 같은 실행기가 만들어지기 이전에는 IDE에서 코드 작성 후, 브라우저에서 결과를 보고, 수정 작업을 거쳐왔었습니다.

이러한 문제를 해결하기 위해 Node.js를 사용합니다. Node.js은 js 런타임 환경이므로, 브라우저 없이도 js를 실행할 수 있게 됩니다.

1. 최신 스펙으로 개발을 할 수 있게 됩니다.
   JS 스펙의 발전 속도보다 브라우저의 지원 속도가 느린데 바벨, 웹팩, NPM 같은 노드 기술로 만들어진 환경에서는 자동화된 프론트엔드 개발환경을 갖출 수 있습니다.
2. 빌드 자동화가 가능합니다.
   코딩 결과물을 파일 압출, 코드 난독화, 폴리필을 추가하는 등 개발 이외의 작업을 거친후에 배포합니다.
   Node.js는 일련의 빌드 과정을 이해하는데 적지 않은 역할을 합니다. 뿐만 아니라 라이브러리 의존성을 해결하고 각종 테스트를 자동화하는데도 사용됩니다.
3. 개발 환경 커스터 마이징이 가능해집니다.

npm이란

npm 공식 홈페이지에서는 npm을 아래와 같이 설명하고 있습니다.

npm은 세계에서 가장 큰 소프트웨어 레지스트리입니다. 모든 대륙의 오픈 소스 개발자들은 npm을 사용하여 패키지를 공유하고 빌립니다. 많은 기관들은 또한 private 개발을 관리하기 위해 npm을 사용합니다

npm은 Node.js로 만들어진 자바스크립트 모듈을 설치하고 관리하는 도구입니다. 개발자는 명령어를 통해 공개된 모듈을 설치하고 활용할 수 있게 됩니다.
(Java의 maven, gradle와 같은 빌드툴과 비슷합니다)

npm 기반으로 프로젝트 시작하기

npm init

• npm 기반의 프로젝트를 생성할 수 있는 명령어입니다.
• 명령어 이후에는 package.json 파일을 생성됨을 확인할 수 있습니다.

package.json: name과 version을 통해 각 패키지의 고유성을 판별하게 됩니다. 따라서 패키지의 내용을 변경하려면 version을 변경해야 합니다.

• name: 필수 속성
• version: 필수 속성
• scripts: 패키지의 생명주기 중 다양한 타이밍에 실행되는 script 명령들을 포함하고 있는 사전
  • scripts 항목 객체에서 키는 이벤트이고, 값은 이 때 실행될 커맨드입니다.
• main: 프로그램의 시작점이 되는 모듈의 ID
  • 모듈 ID는 패키지 루트에 상대적인 경로를 지정해야 합니다.
    • 예) foo라는 패키지가 있다면 이 패키지를 사용자(개발자)가 설치한 뒤, require('foo')를 실행했을 때, main으로 지정한 모듈의 exports 객체가 반환됩니다.
  • 대부분의 모듈에 있어 main 스크립트를 갖는 것은 유용하나 종종 그렇지 않을 수도 있습니다.

npm 버전 번호 관리 체계

node.js는 버전 번호를 관리하기 위한 규칙이 존재하는데, 이를 유의적 버전(Sementic Version)이라고 합니다.

유의적 버전

• 주(Major): 기존 버전과 호환되지 않게 변경된 경우
• 부(Minor): 기존 버전과 호환 & 기능 추가
• 수(Patch): 기존 버전과 호환 & 버그 수정

버전의 범위

유의적 버전을 명세하는 것에서 그치지 않고, 버전의 범위를 자신만의 규칙으로 관리합니다.

1. 특정 버전을 사용하는 경우
   1.2.3
2. 특정버전보다 높거나 낮을 경우
   >1.2.3
>=1.2.3
<1.2.3
<=1.2.3
3. 틸트(~)
   마이너 버전이 명시되어 있으면 패치버전을 변경
   ex) ~1.2.3: 1.2.3부터 1.3.0 미만까지를 포함
   마이너 버전이 없으면 마이너 버전을 갱신
   ex) ~0: 0.0.0부터 1.0.0미만까지를 포함
4. 캐럿(^)
   정식버전에서 마이너와 패치버전을 변경
   ex) ^1.2.3: 1.2.3부터 2.0.0 미만까지를 포함
   정식버전 미만인 0.x 버전은 패치만 갱신
   ex) ^0.0: 0.0.0부터 0.1.0 미만까지를 포함

과거에는 틸트를 사용했지만 최근에는 캐럿을 사용합니다. 왜냐하면 라이브러리 정식 릴리즈 전에는 패키지 번호가 수시로 변경됩니다. 이 때, 0.1에서 0.2로 Minor가 변경되었을 때, 유의적 버전의 의미를 신경쓰기보다는 하위호환성을 지키지 않고 배포하는 경우가 빈번합니다. 때문에, 이를 보완하는 캐럿 범위를 사용하게 되는 것이죠.

출처

• 프론트엔드 개발환경의 이해 (인프런)
• https://resucito.tistory.com/22
• https://programmingsummaries.tistory.com/385