DIL: 모던 리액트 딥 다이브, 5주차-5

스터디: 월간 CS, https://github.com/monthly-cs/2024-03-modern-react-deep-dive
오늘 진행: 개인공부

---

DIL-week5-5_2024-04-05

| DIL 주차 | 범위 | 내용 | 오늘차 진도 | | -------- | ---- | -------------------------------------------------- | ----------- | | 5주차 | 9장 | 모던 리액트 개발 도구로 개발 및 배포 환경 구축하기 | 566p~616p |

오늘 읽은 내용을 markdown으로 간단히 메모
읽은 시간: 9시~11시

---

모던 리액트 개발 도구: 깃허브 100% 활용하기

package.json의 dependencies

semantic versioning 유의적 버전

• 주.부.수

| version | 버전 | 내용 | | ------- | ---- | --------------------------------------- | | Major | 주 | 기존 버전과 호환되지 않게 API가 바뀜 | | Minor | 부 | 기존 버전과 호환되면서 새로운 기능 추가 | | Patch | 수 | 기존 버전과 호환되면서 버그를 수정 |

• 변경 사항이 있으면 반드시 버전업
• Major 0은 초기 개발 ex) recoil
• Patch는 이전 버전 API와 호환되는 버그 수정의 경우에만 올린다 (내부 기능을 고침)
  • 버그 수정이 API 스펙을 변경을 동반한다면, Major를 올린다
  • Major를 올리기 좀 그렇다? API를 deprecated 처리 후, 새 API를 만들어 부 버전을 올리는 것이 좋다

npm 버전 규칙 (유의전 버전 기반)

| 버전 | 내용 | 해당 | | ------------- | ---------------------------------- | --------------------- | | react@16.0.0 | 정확히 해당 버전만 의존 | 16.0.0 | | react@^16.0.0 | 16.0.0과 호환되는 버전 | 16.0.0부터 17.0.0미만 | | react@~16.0.0 | 패치 버전에 대해서만 호환되는 버전 | 16.0.0~16.1.0 미만 |

• 예시) colors.js 라이브러리: 1.4.0에서 1.4.1로 patch 올리는 과정에서 호환안되는 패키지를 배포하는 불상사

dependencies

• package.json의 dependencies: 자신 외의 npm 라이브러리를 정의

| 버전 | 내용 | | | ---------------- | ------------------------------------------------------------- | --------------------------------------------------------------------- | | dependencies | npm install 패키지명 | 프로젝트를 실행하는 데 꼭 필요한 패키지 | | devDependencies | npm install 패키지명 --save-dev | 프로젝트를 실행하는 데는 필요하지 않지만, 개발 단계에서 필요한 패키지 | | peerDependencies | {”peerDependencies”:{”react”:”>=16.8”, ”react-dom”:”>=16.8”}} | 서비스보다는 라이브러리와 패키지에 자주 쓰이는 단위 |

• dev dependencies를 구분해야 할까?
  1. dependencies와 devDependecies 모두 node_modules에 설치한다. 번들러가 코드의 시작점부터 종속성 판단 → 필요한 파일을 빌드해서 결과물을 만듦
     • 애플리케이션 최종 결과물에는 영향이 없다
  2. 복잡해진 개발 파이프라인
     • 옛~날 ⇒ npm install --only=production으로 필요한 패키지 빠르게 설치
     • 지금 이렇게 하면? typescript의 @types/같은 타이핑 파일도 devDependencies에 선언되어 tsc가 실행 안됨
• npm에 업로드할 패키지를 개발한다면?
  • dependencies에 있는 패키지들만 최종 패키지에 포함되게 해야 함
  • 향후 다른 패키지의 의존성을 읽거나 출시하기 위해 차이를 알아야함
• 개발 취약점
  • critical, high, moderate, low
  • react 팀 → false positive에 대해 대응하지 않겠다
    • 취약점이 있으나, 코드를 사용하지 않거나, 문제가 없다고 자체적으로 판단한 취약점은 공식적으로 대응하지 않겠다.
• 의존성 관련 이슈를 방지하는 방법은?
  • 내재화할 수 있는 모듈을 내재화하고, 의존성을 최소한으로 유지한다
    • 위협에 노출될 확률을 낮춘다
    • 웹 애플리케이션 개발에서 어렵다.
  • 활발하게 유지보수되는 패키지를 사용한다.
    • 유지보수 주체가 없다면? 점차 의존성 문제가 당면하게 된다.
• Dependabot과 npm의 overrides를 활용해서 도움을 받기
• Github은 de facto 저장소: Dependabot, Copilot, Github Pages, Private, Enterprise

리액트 애플리케이션 배포하기, SaaS 3가지

• 클라우드 서비스
  • Amazon Web Service
  • Google Cloud Platform
  • Microsoft Azure

리액트 애플리케이션 배포

| SaaS | 특징 | 제공 | 공홈 | | ------------ | ----------------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | | Netlitfy | 루트에 netlify.toml 파일 생성 | 배포 알림, 서비스 통합 Integrations (Sentry, Aloglia, Redis), 서버리스 함수, Identity 인증 | https://www.netlify.com/pricing/ | | Vercel | preset 설정 | 알림, 서버리스 함수, 템플릿 지원🤔 | https://vercel.com/ | | DigitalOcean | 다양한 클라우드 컴퓨팅 서비스 | 알림, 컨테이너 직접 접근, 마켓플레이스(컨테이너 제공 위주), 도메인 연결 | https://www.digitalocean.com/, 블로그 https://www.digitalocean.com/blog |

• TOML은? “Tom’s Obvious, Minimal Language”, YAML 유사
  • https://toml.io/en/

    [[plugins]];
    package = "@netlify/plugin-nextjs";
    

• 쉽고 빠른 배포 ⇒ MVP, 제한적인 트래픽의 사이트