모던 리액트 deep dive 스터디 - 5주차 발표 정리 (9장)
*본 글은 발표 대본용이라 상세 정보는 들어가 있지 않습니다.
9장 모던 리액트 개발 도구로 개발 및 배포 환경 구축하기
우리에게 편리함을 가져다주는 create-react-app과 create-next-app
편리한게 좋긴하지만 어떻게 프로젝트 구조가 잡히는지, 어떤 설정들이 필요한지에 대해서 깊게 생각하지 않고 만들게 된다.
이 편리한 CLI 도구를 사용해보지 않고 프로젝트 환경설정을 해보자.
Next 프로젝트를 위해 설치할 것들
- react
- react-dom
- next
- typescript
- @types/react
- @types/react-dom
- @types/node
- eslint
- eslint-config-next
tsconfig.json
{
"$schema": "https://json.schemastore.org/tsconfig.json"
}
상단에 위 값을 작성하면 JSON 파일이 무엇인지, 어떤 키와 값이 들어갈 수 있는지 알려준다.
tsconfig.json 파헤쳐보기
{
"$schema": "https://json.schemastore.org/tsconfig.json",
"compilerOptions": { => 타입스크립트를 자바스크립트로 컴파일할 때 사용
"target": "es5", => 타입스크립트가 변환을 목표로 하는 언어의 버전
"lib": ["dom", "dom.iterable", "esnext"], => 신규 기능에 대한 API 정보를 확인할 수 있게 해줌.
"allowJs": false, => 타입스크립트가 자바스크립트 파일 또한 컴파일 할지 여부
"skipLibCheck": true, => 라이브러리에서 제공하는 d.ts에 대한 검사 여부
"strict": true, => 엄격 모드 제한
"forceConsistentCasingInFileNames": true, => 파일 이름의 대소문자 구분 여부
"noEmit": true, => 컴파일을 하지 않고, 타입 체크만 할지에 대한 여부
"esModuleInterop": true, => CommonJS 방식으로 보낸 모듈을 ES 모듈 방식의 import로 가져올 수 있게 해줌.
"module": "esnext", => 모듈 시스템 정의 ex) commonjs, esnext
"moduleResolution": "node", => 모듈을 해석하는 방식. node는 node_modules, classic은 tsconfig.json을 기준으로 해석
"resolveJsonModule": true, => JSON 파일을 import하게 해줌.
"isolatedModules": true, => 다른 모듈 시스템과 연계되지 않고 단독으로 있는 파일의 생성을 막기 위한 옵션
"jsx": "preserve", => .tsx 파일 내부에 있는 JSX를 어떻게 컴파일 할지 설정. (현재. 변환하지 않고 그대로 유지 설정)
"incremental": true, => 마지막 컴파일 정보를 .tsbuildinfo 파일 형태로 만들어 디스크에 저장
"baseUrl": "src", => 모듈을 찾을 때 기준이 되는 디렉터리를 지정
"paths": { => 경로에 대한 별칭 지정. 단, @는 가급적 피하길. 네이밍에 따라 충돌 가능성이 있음.
"#pages/*": ["pages/*"],
"#hooks/*": ["hooks/*"],
"#types/*": ["types/*"],
"#components/*": ["components/*"],
"#utils/*": ["utils/*"]
}
},
"include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"], => 컴파일 대상에 포함시킬 파일 목록
"exclude": ["node_modules"] => 컴파일 대상에서 제외시킬 파일 목록
}
깃허브 100% 활용하기
CI란?
Continuous Integration
코드의 변화를 모으고 관리하는 코드 중앙 저장소에서, 여러 기여자가 기여한 코드를 지속적으로 빌드하고 테스트해 코드의 정합성을 확인하는 과정
CI 환경을 구축하기 위해 보통 젠킨스가 많이 사용된다.
잘 구축된 젠킨스 CI 파이프라인으로는 단순히 한 저장소의 코드에 그치지 않고 많은 것들을 수행할 수 있다.
하지만, 젠킨스는 다음의 단점이 존재한다.
- 설치형 솔루션이므로, 별도 서버를 구축
- 서버 내에 젠킨스 설치 및 사용 중인 저장소와 연결
- 유지보수가 번거로움
그렇다면 다른 CI 구축 방법이 또 있을까?
💁♂️ 깃허브 액션
깃허브가 제공하는 가상 환경에서 사용자가 원하는 작업을 수행할 수 있음.
ex)
- 깃허브의 어떤 브랜치에 푸시가 발생한면 빌드를 수행
- 깃허브의 특정 브랜치가 메인 브랜치를 대상으로 풀 리퀘스트가 열리면 빌드, 테스트, 정적 분석을 수행함.
액션 내에는 하나 이상의 잡이 있고, 각 잡은 스텝들로 엮어져있음. (스텝은 하나하나의 작업으로 셀 명령어나 액션의 실행을 말한다.)
깃허브 액션 작성하기
name: chapter9 build => 액션의 이름
run-name: ${{ github. actor }} has been added new commit.
=> 액션이 실행될 때 구별할 수 있는 타이틀명
설정돼 있지 않다면 풀 리퀘스트 이름이나 마지막 커밋 메시지 등이 출력
on: => 필수 값, 언제 이 액션을 실행할지를 정의
push:
branches-ignore:
- 'main' => 이 브랜치에 푸시가 발생했을 때는 실행하지 않는다.
paths:
- ./chapter9/zero-to-next => 이 저장소에 푸시가 되면 실행한다.
jobs: => 필수값, 해당 액션에서 수행할 잡을 정의
build: => name과 같은 역할
runs-on: ubuntu-latest => 어느 환경에서 해당 작업이 실행될지를 결정
ubuntu-latest를 선언하면 깃허브에서 제공하는 서버를 씀.
steps: => 해당 잡에서 순차적으로 수행할 작업을 정의한다.
- uses: actions/checkout@v3 => 깃허브에서 제공하는 기본 액션으로 이 액션을 사용해서 작업한다.
- uses: actions/setup-node@v3
with: => 노드 최신 버전을 같이 설치
node-version: 16
- name: 'install dependencies' => 해당 스텝의 명칭을 지정
working-directory: ./chapter9/zero-to-next => 뒤이어 수행할 작업을 해당 디렉토리에서 수행
run: npm ci => 수행할 작업을 명시
- name: 'build'
working-directory: ./chapter9/zero-to-next
run: npm run build
추가적으로 사용하면 좋을 법한 유용한 액션들을 알아보자.
calibreapp/image-actions
- PR로 올라온 이미지를 sharp 패키지를 이용해 거의 무손실로 압축해서 다시 커밋해준다.
- Next.js 같은 경우에는 이미 next/image로 이미지를 최적화하고 있지만 저장소 자체의 이미지 크기를 줄인다면 풀 할 때 부담을 줄일 수 있다.
lirantal/is-website-vulnerable
특정 웹사이트를 방문해 해당 웹사이트에 라이브러리 취약점이 존재하는지 확인해준다.
Lighthouse CI
라이트하우스를 CI를 기반으로 실행할 수 있도록 도와주는 도구
Dependabot
- 의존성의 문제를 알려주고 해결할 수 있는 풀 리스퀘트를 열어줌.
- 이슈를 찾는 용도로만 사용하고, 절대로 완벽하게 수정해 준다고 맹신하지 말기.
- Dependabot으로 수정하기 어려운 이슈라면 npm의 overrides를 활용해보기. (의존성을 콕 집어서 수정하는 데 매우 유용)
버전
유의적 버전
- 주.부.수
- 개발자들 간의 약속. 너무 맹신해서는 안됨.
1. 기존 버전과 호환되지 않게 API가 바뀔 때 => 주 ⬆️
2. 기존 버전과 호환되면서 새로운 기능을 추가할 때 => 부 ⬆️
3. 기존 버전과 호환되면서 버그를 수정한 것 => 수 ⬆️
중요한 점
- 특정 버전으로 패키지를 배포하고 나면 그 버전의 내용은 절대 변경 x
- 주 버전 0은 초기 개발을 위해 쓴다. 이 때는 마음대로 바꿔도 됨
- 버그 수정이 API 스펙 변경을 동반하면 수 버전이 아닌 주 버전을 올려야함.
의존성
- npm 프로젝트를 운영하는 데 필요한 자신 외의 npm 라이브러리를 정의해 둔 목록
dependencies
- 해당 프로젝트를 실행하는 데 꼭 필요한 패키지
devDependencies
- npm install 패키지명 --save-dev를 통해 추가
- 개발 단계에서 필요한 패키지
=> npm에 업로드할 패키지를 개발할 경우 dependencies와 devDependencies의 구분을 확실히 지어야 한다.
peerDependencies
- 주로 서비스보다는 라이브러리와 패키지에 자주 쓰임
- 직접적으로 해당 패키지를 require, import 하지는 않지만 호환성으로 인해 필요한 경우
{
"peerDependencies": {
"react": ">=16.8"
}
}
- 리액트 16.8 버전 이상이 필요
리액트 애플리케이션 배포하기
3가지 SaaS 서비스의 특징에 대해 정리하겠다.
1. Netlify
- 출시된 지 오래된만큼 다양한 Integration이 존재
- 배포와 관련된 알림 추가 가능
- 외부에서 구매한 도메인을 Netlify DNS를 통해 연결할 수 있다.
- 별도의 서버 구축 없이도 서버에서 실행될 함수를 만들 수 있다.
- Identity 서비스를 통해 유저에 대한 인증 처리를 간편하게 할 수 있음.
- 개인은 Pro 티어 추천, 멤버 한명당 매달 19달러
2. Vercel
- 프레임워크를 선택하면 일반적으로 사용되는 빌드 명령어, 배포 위치, 배포 명령어도 함께 선택할 수 있다.
- 배포의 성공 실패 여부, 기본적인 알림 기능
- 별도로 구매한 도메인 연결 가능
- 서버 없이 함수를 클라우드에 구축해 실행 가능. Next.js에서 제공하는 /pages/api의 내용도 함수로 구분되어 접근로그나 오류 확인 가능
- 다양한 템플릿
- 개인은 Hobby 추천
3. DigitalOcean
- 학생 계정으로 가입시 200달러 상당의 무료 크레딧 제공
- 기본적인 알림 기능
- 컨테이너에 직접 접근하여 필요한 작업 수행 가능
- 애플리케이션에 추가로 설치할 수 있는 다양한 앱 제공
- 외부에서 구매한 도메인 연결
도커라이즈
위에서 나온 SaaS 서비스들은 간단한 과정으로 배포할 수 있다는 것이 큰 장점이다.
하지만, 그만큼 애플리케이션을 자유롭게 커스터마이징하는데는 제약이 있고,
빌드 횟수, 팀 멤버의 수, 사용하는 컨테이너의 스팩 등에 크게 의존하므로 유연한 비용 체계를 유지할 수 없다는 단점도 공존한다.
이번에는 반대로 도커를 이용해서 애플리케이션을 하나의 컨테이너로 만들어서 빠르게 배포할 수 있는 방법을 알아보자.
도커란?
애플리케이션을 빠르게 배포할 수 있도록 애플리케이션을 '컨테이너'라는 단위로 패키징하고, 이 '컨테이너' 내부에서 애플리케이션이 실행될 수 있도록 도와준다.
이때 도커는 운영처제 설치, Node.js 설치, 빌드와 같은 작업들을 대신 해주는 편의성을 제공한다.
프론트엔드 애플리케이션이 도커 이미지에서 해야 할 작업
1. 애플리케이션 정상 구동을 위한 최소한의 운영체제 확보
2. npm 프로젝트 구동을 위한 Node.js 설치
3. 프로젝트 빌드에 필요한 의존성 모듈 설치 (npm ci)
4. 프로젝트 빌드 (npm rub build)
5. 프로젝트 실행
위 과정을 Dockerfile에 기재해보자.
FROM node:18.12.0-alpine3.16 as build => alpine3.16 버전의 운영체제 위에서 실행되는 이미지다
WORKDIR /app => WORKDIR이란 작업을 수행하고자 하는 기본 디렉터리
COPY package.json ./package.json => 파일을 복사
COPY package-lock.json ./package-lock.json
RUN npm ci => 컨테이너에서 실행할 명령어 (의존성 설치)
COPY . ./ => 모든 리소스를 복사
RUN npm run build => 빌드
터미널에서 아래 명령어로 빌드 수행
docker build . -t cra:test- 해당 위치 . 에서 빌드를 수행하며, -t로 이름과 태그로 각각 cra와 test를 부여
'프로그래밍언어 > React' 카테고리의 다른 글
| 모던 리액트 deep dive 스터디 - 7주차 발표 정리 (1) | 2024.04.20 |
|---|---|
| 모던 리액트 deep dive 스터디 - 6주차 발표 정리 (0) | 2024.04.13 |
| 모던 리액트 deep dive 스터디 - 4주차 발표 정리 (0) | 2024.03.30 |
| 모던 리액트 deep dive 스터디 - 3주차 발표 정리 (1) | 2024.03.22 |
| 모던 리액트 deep dive 스터디 - 1주차 발표 정리 (2) | 2024.03.09 |