Create 김동규.md

9장/김동규.md

@@ -0,0 +1,202 @@
+# 9장 모던 리액트 개발 도구로 개발 및 배포환경 구축하기
+
+#스터디-리액트딥다이브
+
+## 9.1 Next.js로 리액트 개발 환경 구축하기
+
+`create-react-app` 과 `create-next-app`은 리액트와 Next.js 애플리케이션을 손쉽게 만들 수 있는 CLI 도구 이다.
+
+```생각 & 의견
+실제 https://react.dev/learn/start-a-new-react-project 보시면 create-react-app 관련 내용이 삭제 되어있었습니다. 한때 깃헙 이슈에서 난리가 났었는데 vite을 뉴노멀로 만들자 parcel 도입하자 등 이야기가 꽤 많았는데 그 이슈를 못찾겠네요..
+```
+
+### 9.1.1 create-next-app 없이 하나씩 구축하기
+
+Pass
+
+### 9.1.2 tsconfig.json 작성하기
+
+- `$schema`는 해당 JSON 파일이 무엇을 의미하지는, 어떤키와 어떤값이 들어갈 수 있는지 알려주는 도구이다.
+
+#### compilerOptions
+
+타입스크립트를 자바스크립트로 컴파일 하는 경우 사용하는 옵션이다.
+
+- target: 타입스크립트가 변환을 목표로 하는 언어의 버전
+- lib: 변환과 다르게 사용 가능한 버전
+- skipLibCheck: .d.ts파일 검사 여부
+
+```생각 & 의견
+저는 켜놓는 편 입니다. .d.ts 파일을 생각보다 많이 사용해서 타입체크가 안되면 많이 불편하더라고요
+```
+
+- strict: 엄격 모드
+- noImplicitAny: 변수에 any 자동할당 비활성화
+- noEmit: 컴파일하지 않고 타입만 체크. Next.js에서는 SWC가 컴파일함
+- esModuleInterop: CJS 방식의 모듈을 import 할 수 있게 허용
+- jsx: .tsx 파일 내부에 있는 JSX를 어떻게 컴파일 할지 설정
+  - react: 기본값, React.CreateElement로 변환된다. 16까지의 기본값
+  - react-jsx: 17에서 등장, react/jsx-runtime을 사용하여 변환. 이 방식을 사용하면 상단에 `import React from 'react`를 적지 않아도 됨
+  - react-jxdev: react-jsx와 동일하지만 디버깅 정보 추가
+  - preserve: 변환하지 않고 그대로 유지
+  - react-native: react-native에서 사용하는 방식, 변환하지 않고 그대로 유지
+
+### 9.1.3 next.config.js 작성하기
+
+pass
+
+### 9.1.4 ESLint와 Prettier 설정하기
+
+eslint-config-next로는 부족하다. @titicaca/eslint-triple을 설치하면 코드 스타일링등 일반적인 작업을 처리해준다. `.next`나 `node_modules`은 정적파일 분석에 필요없음으로 제외하자!
+
+```생각 & 의견
+@titicaca/eslint-triple 라이브러리 보니까 트리플이라는 회사의 config인 것 같네요
+https://github.com/titicacadev/triple-config-kit
+```
+
+### 9.1.5 스타일 설정
+
+styled-component를 사용한다면 next.config.js에 styledComponent 옵션을 true로 바꿔주어 SWC에게 styled-component를 사용한다는 것을 알려주자.
+
+```생각 & 의견
+emotion도 있어요!
+```
+
+### 9.1.6 애플리케이션 코드 작성
+
+Next.js 애플리케이션 코드는 `src/page`아래 실제 라우팅과 관련된 파일을 기재해야 한다. 폴더 구조에 정답은 없다. 팀에서 잘 정해서 최선의 구조를 사용하자
+
+### 9.1.7 정리
+
+이런 프로젝트를 매번 만드는것은 귀찮기 때문에 Gituhb의 template이나 CLI로 만들어서 사용해보자
+
+## 9.2 깃허브 100% 사용하기
+
+1억개가 넘는 공개 저장소가 있으며, 어느 회사나 조직을 가더라도 깃허브를 쓰는게 사실상 표준인 널리 사랑받는 서비스이다.
+
+### 9.2.1 깃허브 액션으로 CI 환경 구축하기
+
+CI란, 여러 기여자가 기여한 코드를 지속적으로 빌드하고 테스트해 코드의 정합성을 확인하는 과정을 말한다. 깃허브 액션에서 자주나오는 기본 개념은 아래와 같다.
+
+- 러너(runner): 깃허브 액션이 실행되는 서버를 말한다.
+- 액션(action): 러너에서 실행되는 액션의 단위를 의미한다.
+- 이벤트(event): 액션을 일으키는 이벤트를 의미한다. pull_requsest, issues 등이 있다.
+- 잡(jobs): 하나의 러너에서 실행 되는 여러 스텝의 모음을 의미한다.
+- 스탭(steps): 잡 내부에서 일어나는 하나하나의 작업을 의미한다.
+
+액션을 작성하려면 저장소 루트의 `.github/workflows` 폴더를 생성하고 내부에 `.yml` 또는 `.yaml`로 파일을 작성하면 된다.
+
+#### 브랜치 보호 규칙
+
+머지하기전에 꼭 성공해야 하는 규칙이 있다면 저장소의 Branch 옵션의 `Add branch protection rule`을 클릭해 브랜치 보호 규칙을 추가해보자.
+
+### 9.2.2 직접 작성하지 않고 유용한 액션과 깃허브 앱 가져다 쓰기
+
+#### 깃허브 제공 기본 액션
+
+- actions/checkout: 깃허브 저장소를 체크아웃 하는 액션
+- actions/setup-node: Node.js를 설치하는 액션
+- actions/github-scripts: Github가 제공하는 API를 사용할 수 있게 해주는 액션
+- actions/stale: 오래된 이슈나 PR을 자동으로 닫거나 해주는 액션
+- actions/dependency-review-action: 의존성 그래프, 즉 package.json 등의 내용이 변경 되었을 때 실행되는 액션.
+- actions/codeql-action: 깃허브 코드 분석 솔루션인 code-ql을 활용해 저장소 내 취약점을 분석해준다.
+
+#### lirantal/is-website-vulnerable
+
+특정 웹사이트에 방문하여 해당 웹사이트 라이브러리에 취약점이 존재하는 지확인 하는 깃허브 액션. 취약점이 포함된 패키지는 배포가 안되게 하는게 좋지만 혹시 모르니 주기적으로 검사하는 것이 좋다. 배포 액션의 잡 중에 needs: \*\*\* 구문을 추가해 배포 잡이 끝난 후에 실행 시키거나, 별도의 액션을 추가하여 on.workdlow_run으로 실행 하는 방법도 있다.
+
+#### Lighthous CI
+
+구글에서 제공하는 액션으로 웹 성능 지표인 라이트하우스를 CI 기반으로 실행할 수 있도록 도와 주는 도구다.
+
+### 9.2.3 깃허브 Dependabot으로 보안 취약점 해결하기
+
+깃허브에서 제공하는 강력한 기능 중 하나로, 문제 발생 시 PR까지 열어준다.
+
+#### 버전
+
+주.부.수 형태로 관리한다. npm 버전의 규칙은 아래와 같다
+
+- [email protected]: 정확히 해당 버전에만 의존한다
+- react@^16.0.0: 0보다 높은 부버전에 대해서는 호환된다라는 가정하에 설치 가능하다. 주 버전이 0 인경우, 부 버전이 올라가도 변경이 있을 수 있음으로 수 버전까지만 수용
+- react@~16.0.0: 패치(수) 버전에 대해서만 호환된다라는 것을 의미한다.
+
+#### 의존성
+
+패키지를 구분하는 것에 의문을 제기하는 목소리가 있다.
+
+- 번들러로 인해 devDepdencies, dependencies 상관없음
+- 개발 파이프라인이 복잡해졌다.
+  하지만, npm에 업로드 할 패키지를 개발한다면 중요해진다.
+
+Dependabot은 Critical, Hight, Moderate, Low 4단계로 나눈다.
+
+```sh
+npm list
+```
+
+명령어를 통해 취약점이 발견된 패키지를 찾을 수 있다. PR이 열린 경우 머지를 해서 해결할 수 있다. 반대로 PR이 생성되지 않았을 경우는 직접 버전을 업데이트 한다. 이런 문제를 해결할 수 있는 가장 좋은 방법은 의존성을 가장 적게 유지하는 것이다.
+
+### 9.2.4 정리
+
+깃허브만 잘 활용해도 코드 관리에 필요한 거의 대부분의 기능을 이용할 수 있다. 꾸준히 코드를 작성할 예정이라면 프로계정을 사용보자!
+
+## 9.3 리액트 애플리케이션 배포하기
+
+별도의 서버를 마련하지 않고 쉽게 배포하는 방법 3가지!!
+
+### 9.3.1 Netlify
+
+SSR로 배포하는 경우 서버가 필요함으로 `netlify.toml`이라는 파일을 생성해서 프로젝트 루트에 포함시켜야 한다. YML 형태로 작성 가능하고, 아래의 코드를 작성해주면 된다.
+
+```yml
+[[plguin]]
+package = "@netlify/plugin-nextjs"
+```
+
+무료로 사용하는 경우 몇가지 제약사항이 있다.
+
+- 대역폭: 월 대역폭 최대 100GB 제한
+- 빌드 시간: 빌드 소비시간 최대 300분
+- 동시 빌드: 순차적으로 빌드해야함. 여러사이트 라도 마찬가지
+
+### 9.3.2 Vercel
+
+Netlify 와 다르게 프로젝트의 디렉토리를 선택하여 배포한다. 무료로 사영하는 경우 제약사항은 다음과 같다.
+
+- 대역폭: 월 최대 100GB
+- 이미지 최적화: 최적화 이미지 1000개 제한
+- 서버리스 함수: 함수 실행시간 100GB제한 되며 시간은 10초 이내
+- 동시 빌드: Netifly와 동일
+- 배포: 하루에 100개로 제한
+
+### 9.3.3 DigitalOcen
+
+학생 계정으로 가입한 깃허브에 200달러 상당의 크레딧 제공. 문서화와 블로그도 운영하며 포스팅을 자주 한다.
+Vercel과 Netlify는 정적인 웹사이트에 초점을 둔다면, DigitalOcean은 AWS, GCP와 같은 클라우드 컴퓨팅 서비스에 중점을 둔다.
+컨테이너의 스펙, 애플리케이션의 갯수에 따라 가격이 달라진다.
+
+## 9.4 리액트 애플리케이션 도커라이즈하기
+
+앞선 방법들은 간편하게 사용하기는 좋지만 자유롭게 커스터마이징 하는데 분명 제약이 있다. 도커를 사용해 컨테이너로 만든다면 특정 서비스에 종속적이지 않은 유연한 상태로 만들 수 있다.
+
+### 9.4.1 리액트 앱을 도커라이즈 하는 방법
+
+도커라이즈는 애플래케이션을 신속하게 구축해 배포할 수 있는 상태로 준비하는 것을 말한다. 도커는 애플리케이션을 `컨테이너`라는 단위로 패키징하고 내부에서 애플리케이션이 실행될 수 있게 해준다.
+
+#### create-next-app Dockerfile 작성하기
+
+next.config.js의 `output` 옵션은 빌드를 위해 제공하는 기능으로, 프로덕션에 필요한 파일만을 모아서 바로 실행할 수 있는 준비를 대신 해준다. (node_modeuls 포함)
+빌드된 서버파일을 확인해보면 NextServer를 꺼내온 다음, http.createServer로 만든 서버에 NextServer를 연동한다.
+
+### 9.4.2 도커로 만든 이미지 배포하기
+
+배포할 수 있는 곳은 도커 허브를 포함한 AWS의 ECR 및 GCP의 Container Registry 등이 있다.
+
+### 9.4.3 정리
+
+기업에서는 도커로 히스토리 남기거나 롤백도 자주 하기 어느정도는 알고 있어야 한다. 추가적으로 쿠버네티스를 이용한 탄력적 배포 및 관리가 가능하고 헬름차트를 활요해 정적인 쿠버네티스 플랫폼을 상황에 맞게 관리할 수 있다.
+
+```추가정리
+헬름은 쿠버네티스에서 애플리케션을 배포하기 위해 사용되는 대표적인 패키징 툴이다. 헬름차트는 쿠버네티스 리소스를 하나로 묶은 패키지에 해당한다. 헬름으로 차트를 관리하는 목적은 여러개의 ymal파일 관리하기 쉽게 하기 위해서이다.
+```