프론트엔드 개발환경 세팅(1)

July 02, 2023

일지#1

1주 : 이전 강의 정리포스팅, 계획, 섹션0, 섹션1
라이브러리, 프레임워크에서는 편한방식의 스타트 환경을 제공한다 (CRA, Vue cli)
하지만 이런 환경구성을 아는 것 vs 모르는 것 차이가 있음
유능한 프로그래머가 되기 위해 직접 도구를 다루는 법을 배울 예정
이론 → 실습 (11개의 실습 꼭 따라하기)

오늘 한 것

node.js 설치
npm 설치
npm init
pakage.json 확인
scripts를 통해 명령어 사용하는 법
패키지 설치
유의적 버전

강의자료

프론트엔드 개발환경의 이해: NPM

개인 공부

Node.js?

서버에서 사용하는 스크립트 ?

Node.js는 Chrome V8 JavaScript 엔진 기반의 서버 사이드 JavaScript 런타임

Node.js는 이벤트 기반, 비동기식, 싱글 스레드 모델을 사용하여 경량화되고 빠르게 동작합니다. 이는 Node.js가 동시에 많은 연결을 처리하면서도 일정한 성능을 유지할 수 있게 합니다. Node.js는 네트워크 애플리케이션 개발과 같이 I/O 작업이 주로 발생하는 상황에서 뛰어난 성능을 보여줍니다.

⇒ 성능

또한 Node.js는 npm(Node Package Manager)이라는 패키지 관리자를 통해 다양한 외부 모듈과 라이브러리를 사용할 수 있습니다. 이러한 모듈과 라이브러리는 개발자들이 애플리케이션을 개발하거나 서버를 구축하는 데 도움이 되는 많은 기능을 제공합니다.

⇒ 패키지 관리

Node.js는 JavaScript를 사용하여 서버 측 애플리케이션을 개발하고 실행할 수 있게 해주는 강력한 도구입니다. 이를 통해 개발자들은 JavaScript의 유연성과 풍부한 생태계를 활용하여 효율적이고 확장 가능한 서버 애플리케이션을 구축할 수 있습니다.

⇒ 서버 개발 가능 (확장성)

프론트엔드 개발자가 Node.js에 대해 알아야 하는 이유

서버 사이드 렌더링: Node.js는 서버 측에서 JavaScript를 실행할 수 있는 환경을 제공합니다. 이를 통해 프론트엔드 개발자는 서버 사이드 렌더링을 구현하여 초기 페이지 로딩 속도를 향상시킬 수 있습니다.
빌드 도구와 자동화: Node.js 기반의 도구들(예: Webpack, Gulp, Grunt)은 프론트엔드 개발에서 필수적인 빌드, 번들링, 테스트, 자동화 작업 등을 처리하는 데 사용됩니다. Node.js를 알고 있으면 이러한 도구를 이해하고 사용할 수 있습니다. ⇒ (이게 본 강의를 듣는 이유인 듯)
패키지 관리자와 모듈 생태계: Node.js의 패키지 관리자인 npm은 수많은 오픈 소스 모듈과 라이브러리를 제공합니다. 프론트엔드 개발자는 npm을 사용하여 프로젝트에 필요한 외부 모듈을 쉽게 추가하고 관리할 수 있습니다.
API 개발 및 데이터 처리: Node.js는 웹 API를 개발하기에 적합한 도구입니다. 프론트엔드 개발자는 Node.js를 사용하여 서버 사이드에서 데이터를 처리하고 API를 제공하는 백엔드 서비스를 개발할 수 있습니다.
전체 스택 개발에 기여: 프론트엔드 개발자가 Node.js를 이해하고 활용할 수 있다면, 전체 스택 개발에서 백엔드 개발자와 협업하거나 필요한 작업을 스스로 수행할 수 있습니다. 이는 프로젝트의 효율성과 생산성을 높일 수 있습니다.

요약하자면, Node.js를 알고 있는 프론트엔드 개발자는 서버 사이드 렌더링, 빌드 도구와 자동화, 패키지 관리, API 개발 및 전체 스택 개발 등 다양한 측면에서 유리한 경험과 기술을 갖출 수 있습니다.

프로젝트 초기화

개발 프로젝트는 외부 라이브러리를 다운로드 받고 빌드하는 등 일련의 명령어를 자동화하여 프로젝트를 관리하는 도구가 존재한다.

PHP의 컴포져(Composer)
자바의 그래들(Gradle)

같은 툴이 그러한 프로그램이다. NPM은 자바스크립트 기반 프로젝트의 빌드 도구인 셈이다. NPM을 이용해 프론트엔드 개발 프로젝트를 세팅해 보자.

// 프로젝트 초기 생성 명령어
npm init

// package.json
{
  "name": "sample",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

// name: 프로젝트 이름
// version: 프로젝트 버전 정보
// description: 프로젝트 설명
// main: 노드 어플리케이션일 경우 진입점 경로. 프론트엔드 프로젝트일 경우 사용하지 않는다.
// scripts: 프로젝트 명령어를 등록할 수 있다.초기화시 test 명령어가 샘플로 등록되어 있다
// author: 프로그램 작성자
// license: 라이센스

//*echo : echo 명령어는 주로 컴퓨터의 터미널이나 명령 프롬프트에서 사용되는 명령어

npm의 다양한 명령어 종류

❯ npm -help

Usage: npm <command>

where <command> is one of:
    access, adduser, audit, bin, bugs, c, cache, ci, cit,
    clean-install, clean-install-test, completion, config,
    create, ddp, dedupe, deprecate, dist-tag, docs, doctor,
    edit, explore, fund, get, help, help-search, hook, i, init,
    install, install-ci-test, install-test, it, link, list, ln,
    login, logout, ls, org, outdated, owner, pack, ping, prefix,
    profile, prune, publish, rb, rebuild, repo, restart, root,
    run, run-script, s, se, search, set, shrinkwrap, star,
    stars, start, stop, t, team, test, token, tst, un,
    uninstall, unpublish, unstar, up, update, v, version, view,
    whoami

패키지설치

CDN
- 간단한 방법은 CDN(컨텐츠 전송 네트워크)으로 제공하는 라이브러리를 직접 가져 오는 방식이다
```
<script src="https://unpkg.com/react@16/umd/react.development.js"></script>
```
- CDN 서버 장애로 인해 외부 라이브러리를 사용할 수 없다면 어떻게 될까? 아무리 우리 어플리케이션 서버가 정상이더라도 필수 라이브러리를 가져오지 못한다면 웹 어플리케이션은 정상적으로 동작하지 않을 것이다.****
직접 다운로드
- CDN을 사용하지 않기 때문에 장애와 독립적으로 웹 어플리케이션을 제공할 수 있을 것같다.
- 라이브러리는 계속해서 업데이트 될 것이고 우리 프로젝트에서도 최신 버전으로 교체해야 한다. 매번 직접 다운로드하는 것은 매우 귀찮은 일이 될 것이다. 버전에 따라 하위 호환성 여부까지 확인하려면 실수할 여지가 많다.

NPM

npm install react

// package.json
"dependencies": {
   "react": "18.2.0"
 }

유의적버전(Sementic Version)

유의적 버전은 주(Major), 부(Minor), 수(Patch) 세 가지 숫자를 조합해서 버전을 관리한다. 위에 설치한 react의 버전은 v18.2.0인데 주 버전이 18, 부 버전이 2, 수 버전이 0인 셈이다.

각 버전을 변경하는 기준은 다음과 같다
- 주 버전(Major Version): 기존 버전과 호환되지 않게 변경한 경우
- 부 버전(Minor version): 기존 버전과 호환되면서 기능이 추가된 경우
- 수 버전(Patch version): 기존 버전과 호환되면서 버그를 수정한 경우
버전의 범위
- 가장 단순한 것이 특정 버전을 사용하는 경우다.
1.2.3
- 특정 버전보다 높거나 낮을 경우는 다음과 같이 명시한다.
`>1.2.3

=1.2.3 <1.2.3 <=1.2.3`
- 틸드(~)와 캐럿(^)을 이용해 범위를 명시한다.
~1.2.3 ^1.2.3

틸트(~) 는 마이너 버전이 명시되어 있으면 패치버전만 변경한다. 예를 들어 ~1.2.3 표기는 1.2.3 부터 1.3.0 미만 까지를 포함한다. 마이너 버전이 없으면 마이너 버전을 갱신한다. ~0 표기는 0.0.0부터 1.0.0 미만 까지를 포함한다.

캐럿(^) 은 정식버전에서 마이너와 패치 버전을 변경한다. 예를 들어 ^1.2.3 표기는 1.2.3부터 2.0.0 미만 까지를 포함한다. 정식버전 미만인 0.x 버전은 패치만 갱신한다. ^0 표기는 0.0.0부터 0.1.0 미만 까지를 포함한다.

보통 라이브러리 정식 릴리즈 전에는 패키지 버전이 수시로 변한다. 0.1에서 0.2로 부버전이 변하더라도 하위 호환성을 지키지 않고 배포하는 경우가 빈번하다. ~0로 버전 범위를 표기한다면 0.0.0부터 1.0.0미만까지 사용하기 때문에 하위 호완성을 지키지 못하는 0.2로도 업데이트 되어버리는 문제가 생길수 있다.

반면 캐럿을 사용해 ^0.0으로 표기한다면 0.0.0부터 0.1.0 미만 내에서만 버전을 사용하도록 제한한다. 따라서 하위 호완성을 유지할 수 있다. (자세한 내용은 여기를 참고)

NPM으로 패키지를 설치하면 package.json에 설치한 버전을 기록하는데 캐럿 방식을 이용한다. 초기에는 버전 범위에 틸트를 사용하다가 캐럿을 도입해서 기본 동작으로 사용했다. 그래서 우리가 설치한 react는 ^16.12.0 표기로 버전 범위를 기록한 것이다.
- 읽을 자료

프론트엔드 개발자 이지원입니다.@thinkanddoit

🍎 경험주의자 입니다. 🙋🏻‍♂️ 함께 성장하는 것을 좋아합니다. 📈 꾸준히 성장하기 위한 습관을 들입니다. 🤔 프로세스 고도화에 관심이 있습니다. 🗣 스몰톡을 좋아합니다. ☕️ 커피를 좋아합니다. ⚽️ 축구를 좋아합니다.

GitHub Velog Resume