[PPLOG] 프로젝트 프론트엔드 세팅하기

김현중·2024년 9월 16일

ESLint Husky Next.js 14 Prettier typescript

PPLOG

목록 보기

1/14

카카오 엔터프라이즈 5기 먀옹팀의 프로젝트 PPLOG의 프론트엔드 기본 세팅 과정입니다.

💀Next.js 14 세팅

Next.js란 무엇인가?

Next.js는 리액트 기반의 풀스택 웹 프레임워크로, 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 클라이언트 사이드 렌더링(CSR) 등 다양한 렌더링 방식을 지원합니다.

세팅하기

실행환경 - 윈도우OS
create-next-app을 이용해 프로젝트를 생성하기 위해서는, 먼저 명령 프롬프트를 실행한 다음 명령어를 입력합니다.

npx create-next-app@latest popolog

기존에는 명령어 끝에 --typescript를 입력한다면 TypeScript 환경이 함께 설정이 되지만, Next.js 14버전부터는 npx cna 명령어를 입력한 뒤에 타입스크립트 설정 여부를 묻는 문구가 나타납니다.
이 프로젝트에서는 Next.js 14와 TypeScript를 함께 사용합니다.

이렇게 프로젝트를 생성한 뒤에 vscode등의 IDE를 사용해 프로젝트를 열고, 터미널에 npm run dev를 입력해 개발 서버를 실행할 수 있습니다.

개발 서버가 실행되면 기본적으로 localhost:3000에서 프로젝트를 확인할 수 있습니다.

Next.js 14를 사용한 이유

Next.js 14는 다음과 같은 장점이 있습니다.

최신 기능과 성능 최적화

Next.js 14는 React 18과 호환되며, 서버 컴포넌트, 동적 가져오기 등 React 18에서 추가된 기능들을 활용할 수 있습니다. 이로 인해 더 빠르고 효율적인 렌더링을 구현할 수 있습니다. 그리고 최신 Vercel의 기능을 활용해 배포, 성능 모니터링, 캐시 관리를 더 효율적으로 할 수 있습니다.

서버 컴포넌트

Next.js 14에서는 서버 컴포넌트를 쉽게 사용할 수 있습니다. 서버에서만 실행되는 컴포넌트로, 클라이언트 사이드에서 불필요한 js를 줄여 성능을 최적화합니다.
(ex: 사용자에겐 안보이는 백엔드 연산이 필요한 로직은 서버에서 처리하고, 클라이언트에는 최소한의 결과만 전달하기)

App Router

Next.js 14의 App Router는 기존의 페이지 기반 라우팅보다 더 효율적인 라우팅 체계를 제공합니다. 이 구조는 폴더 기반으로 쉽게 관리 가능하며, 직관적인 설정을 제공합니다.

자동 최적화(Auto-Optimization)

Next.js는 기본적으로 코드를 정적으로 분석하여 자동으로 성능을 최적화합니다. 이미지 최적화, CSS와 JS의 코드 분할, API 라우팅 최적화 등 다양한 자동화 기능이 포함되어 있습니다.

SEO 최적화

SSR을 통해 페이지가 로드될 때 이미 완성된 HTML을 반환하기 때문에 검색 엔진에 더 잘 노출됩니다. Next.js는 이러한 SEO 최적화를 기본적으로 지원하여 검색 엔진의 인덱싱 효율성을 높입니다.

즉 SSR, 최적화 기능 등을 제공해 효율적인 풀스택 웹 개발 환경을 지원합니다.

TypeScript를 사용한 이유

TypeScript는 JS에 정적 타입을 추가한 언어로, Next.js와 결합하여 더 안정적이고 유지보수하기 쉬운 애플리케이션을 개발하도록 해줍니다.

TypeScript는 다음과 같은 장점이 있습니다.

타입 안전성

코드 자동 완성과 IntelliSense

디버깅 시간 단축

유지보수에 용이

IntelliSense(지능형 코드 완성, 코딩을 보다 편리하게 하는 기능 집합에 지정된 이름)

즉 Typescript는 개발 생산성을 높여주고 코드의 품질을 유지하는 데 큰 도움이 됩니다.

📝ESLint 세팅

ESLint란 무엇인가?

ESLint는 JavaScript와 TypeScript 코드의 품질을 향상시키기 위한 정적 코드 분석 도구입니다.
코드 작성 시 발생할 수 있는 오류를 사전에 잡아주고, 일관된 코드 스타일을 유지하는 데 도움을 줍니다.
ESLint는 단순한 문법 오류를 잡아내는 것뿐만 아니라, 코드의 가독성과 유지보수를 높이기 위해 다양한 규칙을 적용하여 개발자가 더 나은 코드를 작성하도록 유도합니다.

정적 분석 도구 : 소스 코드의 실행 없이 코드의 의미를 분석해 결함을 찾아내는 도구

세팅하기

Airbnb의 스타일을 적용하기 위해 eslint-config-airbnb의 peer dependencies를 설치하기

// eslint-config-airbnb와 그 peer dependencies를 수동으로 설치(eslint-config-airbnb와 필요한 모든 peer dependencies를 한 번에 설치합니다.)
npm install -D eslint-config-airbnb eslint eslint-plugin-import eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-jsx-a11y

그 다음 eslint.config 파일을 다음과 같이 작성합니다.

{
  "env": { // 코드가 실행될 환경을 지정
    "browser": true, // 브라우저 환경을 위한 전역 변수 허용(
    "es6": true, // ES6 기능을 사용하도록 설정 (예: let, const, 화살표 함수 등)
    "node": true // Node.js 환경을 위한 전역 변수 허용 (예: require, module 등)
  },
  "extends": [ // 다른 ESLint 설정을 확장
    "airbnb", // Airbnb의 JavaScript 가이드 적용
    "airbnb-typescript", // Airbnb 스타일 가이드에 TypeScript 규칙 추가
    "airbnb/hooks", // React Hooks를 위한 Airbnb의 스타일 가이드 적용
    "plugin:@typescript-eslint/recommended", // Typesciprt 관련 린팅 규칙 추가. 타입 검사과 관련된 권장 규칙 포함
    "plugin:prettier/recommended", // Prettier와 ESLint의 충돌을 방지하기 위한 규칙 세트를 적용. 코드 포매팅도 자동으로 처리
    "prettier" // Prettier 포맷터를 사용하여 린트 규칙을 포매팅 규칙과 일치시킴
  ],
  "parser": "@typescript-eslint/parser", // TypeScript 파일을 파싱하기 위한 파서를 지정
  "parserOptions": {
    "project": "./tsconfig.json" // TypeScript 설정 파일(tsconfig.json)의 경로를 지정하여 프로젝트 설정을 따름
  },
  "plugins": ["@typescript-eslint", "react", "prettier"], // TypeScript, React, Prettier 관련 ESLint 플러그인들을 추가
  "ignorePatterns": ["node_modules/"], // ESLint가 검사하지 않을 경로를 지정. node_modules 폴더는 무시됨
  "rules": {
    "react/react-in-jsx-scope": 0, // React 17 이상에서는 JSX 파일에서 React를 import 하지 않아도 되므로 비활성화
    "react/prefer-stateless-function": 0, // 상태가 없는 함수형 컴포넌트를 권장하는 규칙을 비활성화. 클래스형 컴포넌트도 허용
    "react/jsx-filename-extension": 0, // JSX를 사용하는 파일의 확장자 규칙을 비활성화. js, jsx 외에 ts, tsx 파일에서 JSX 사용 가능
    "react/jsx-one-expression-per-line": 0, // 한 줄에 JSX 표현식을 하나만 사용해야 한다는 규칙을 비활성화
    "no-nested-ternary": 0 // 중첩 삼항 연산자를 허용.
  }
}

Airbnb의 엄격한 스타일 가이드를 기본으로 하되, 프로젝트의 필요에 따라 일부 규칙을 조정했습니다. 그리고 Prettier와의 통합을 통해 코드 포맷팅도 관리하고 있습니다.

터미널에 npx eslint .를 입력하면 프로젝트 코드가 이 규칙을 잘 지키고 있는지 검사할 수 있습니다. Airbnb 스타일 가이드를 따르지 않는 코드에 대해 경고나 에러가 표시됩니다.

Airbnb ESLint 스타일을 사용한 이유

Airbnb ESLint를 사용하는 이유는 최고의 코드 품질을 유지하면서 일관된 스타일을 보장하고, React와 최신 JavaScript에 대한 지원을 제공하기 때문입니다. 엄격한 스타일 규칙은 코드의 가독성, 유지보수성, 협업 효율성을 모두 향상시키며, 이를 통해 개발자는 더 나은 코드 품질을 보장받을 수 있습니다.

또한, Airbnb ESLint 규칙은 프로젝트의 필요에 따라 커스터마이징할 수 있으며, 이를 통해 프로젝트 성격에 맞춰 규칙을 수정하거나 추가할 수 있으며, 이를 통해 프로젝트의 코드베이스에 최적화된 규칙을 적용할 수 있다는 장점이 있습니다.

🐺Husky 세팅

Husky란 무엇인가?

Husky는 Git hooks를 간편하게 관리할 수 있도록 도와주는 JavaScript 도구입니다. Git hooks는 Git이 특정 작업(예: 커밋, 푸시 등)을 수행하기 전에 자동으로 실행할 수 있는 스크립트입니다.
Git hooks를 사용하면 커밋을 하기 전에 코드 스타일을 검사하거나 테스트를 자동으로 실행할 수 있으며, Husky는 이러한 Git hooks를 설정하고 관리하는 과정을 더 쉽게 만들어줍니다.

ESLint와의 차이점

✋잠깐! 이렇게 보면 ESLint와 Husky가 같은 역할을 하고 있다고 생각할 수 있습니다(제가 그랬음).
하지만 ESLint와 Husky에는 다음과 같은 차이점이 있습니다.

실행 시점의 차이 :

ESLint: 주로 개발 중에 에디터나 IDE에서 실시간으로, 또는 빌드 프로세스의 일부로 실행됩니다.

Husky: Git hooks를 통해 커밋이나 푸시 직전에 실행됩니다.

적용 범위의 차이 :

ESLint: JavaScript와 TypeScript 코드에 대한 린팅을 수행합니다.

Husky: ESLint 실행뿐만 아니라, 테스트 실행, 다른 언어의 린팅, 커밋 메시지 검사 등 다양한 작업을 Git hooks에 연결할 수 있습니다.

팀 전체의 일관성 :

ESLint: 개개인의 개발 환경 설정에 따라 다르게 적용될 수 있습니다.

Husky: 프로젝트 저장소에 설정을 포함시켜 모든 팀원에게 동일하게 적용할 수 있습니다.

따라서 Husky는 ESLint와 함께 사용되어 코드 품질 관리를 더욱 강화하는 도구라고 볼 수 있습니다.

세팅하기

다음 명령어를 사용해 Husky를 npm install합니다.

npm install husky --save-dev

그 다음 Husky를 초기화하고 Git hooks를 설정합니다.

npx husky install

package.json에 다음 스크립트를 추가하여 다른 개발자들도 Husky를 자동으로 설치하도록 합니다.

{
  "scripts": {
    "prepare": "husky install"
  }
}

pre-commit 훅을 추가하여 커밋 전에 lint와 테스트를 실행합니다.

npx husky add .husky/pre-commit "npm run lint && npm test"

이 명령어를 통해 .husky/pre-commit 파일이 생성됩니다. 다음과 같이 입력이 되어있습니다.

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

# Lint 코드
npm run lint

# 코드 형식 자동 수정
npx prettier --write .

그 다음 package.json에 다음과 같은 스크립트를 작성할 수 있습니다.

  "scripts": {
    "dev": "next dev", // 개발 모드를 실행하는 스크립트. Next.js 개발 서버를 시작하여 실시간으로 코드 변경 사항을 반영
    "build": "next build", // Next.js 애플리케이션을 프로덕션 환경에 맞게 빌드하는 스크립트. 빌드된 파일을 최적화하여 배포 준비함
    "start": "next start", // 프로덕션 빌드된 Next.js 애플리케이션을 실행하는 스크립트. 배포된 상태에서 서버를 시작할 때 사용
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx", // 프로젝트 전체에서 ESLint를 실행하여 '.js', '.jsx', '.ts', '.tsx' 확장자를 가진 파일들의 코드를 검사하는 스크립트. 코드 품질과 규칙 준수 여부를 확인
    "lint:fix": "eslint . --ext .js,.jsx,.ts,.tsx --fix", // ESLint를 실행하여 코드 스타일 문제를 자동으로 수정하는 스크립트. `.js`, `.jsx`, `.ts`, `.tsx` 확장자를 가진 파일들에서 수정 가능한 문제를 해결
    "format": "prettier --write .", // Prettier를 사용해 프로젝트의 모든 파일을 자동으로 포맷팅하는 스크립트. 코드 스타일을 일관되게 유지함
    "prepare": "husky install" // Husky를 설치하는 스크립트. Git hooks를 설정하여 커밋 전이나 푸시 전에 실행할 작업을 준비
  },

Husky를 사용해 커밋 메시지 검사 추가

위와 같이 Husky의 기본 세팅 후, 커밋 메시지 형식을 검사하기 위해 commitlint를 설치하고 설정할 수 있습니다.

npm install @commitlint/cli @commitlint/config-conventional --save-dev

그 다음 commitlint.config.ts 파일을 생성하고 다음과 같이 작성합니다.

module.exports = {
  // commitlint-plugin-function-rules 플러그인을 사용
  plugins: ['commitlint-plugin-function-rules'],
  rules: {
    // 커밋 타입 제한(오류 레벨: 2는 오류를 의미), 타입은 아래 배열 요소 중 하나로 해야 함
    'type-enum': [
      2,
      'always',
      ['feat', 'fix', 'refactor', 'design', 'comment', 'style', 'test', 'chore', 'init', 'rename', 'remove'],
    ],
    'type-case': [2, 'always', 'lower-case'], // 커밋 타입은 항상 소문자
    'subject-empty': [2, 'never'], // 커밋 제목은 비어있으면 안됨
    'subject-full-stop': [2, 'never', '.'], // 커밋 제목은 마침표로 끝나면 안됨
    'body-leading-blank': [2, 'always'], // 커밋 본문 앞에는 빈 줄이 있어야 함
    'body-max-line-length': [2, 'always', 100], // 커밋 본문의 각 줄은 최대 100자
    'header-max-length': [2, 'always', 100], // 커밋 헤더(타입 + 제목)는 최대 100자
  },
};

작성한 커밋 규칙을 사용하기 위해 다음과 같은 단계를 추가 진행합니다.

필요 패키지 설치

npm install --save-dev commitlint-plugin-function-rules

Husky 설정

npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

이제 커밋 메시지는 다음과 같은 형식을 따라야 합니다.

<type>: <emoji> <subject>

[optional body]

[optional footer]

실제 적용 예시

프로젝트 폴더에는 아래와 같이 커밋 규칙이 적힌 txt 파일이 있습니다.

# 커밋 메시지 템플릿
# 아래 형식에 따라 커밋 메시지를 작성해주세요.
# 줄 시작의 "#" 기호는 주석을 나타내며, 커밋 메시지에 포함되지 않습니다.

# --- 제목 행 --- #
# 타입: 제목 (헤더의 최대 길이는 100자)
# 사용 가능한 타입: feat, fix, refactor, design, comment, style, test, chore, init, rename, remove
# 타입은 소문자만 사용
# 제목 끝에 마침표(.) 사용 금지
<type>: <subject>

# --- 본문 --- #
# 본문 시작 전 빈 줄 필수
# 본문의 각 줄은 100자를 넘지 않아야 함
# 변경 이유와 변경 전과의 차이점 설명
<body>

# --- 꼬리말 --- #
# 꼬리말은 옵션이며, 이슈 트래커 ID를 참조하는 데 사용
# <type>: <description> [<issue-reference>]
# 예: Closes: #123
<footer>

# --- 커밋 타입 설명 --- #
# ✨ feat : 새로운 기능 추가
# 🐛 fix : 버그 수정
# ♻️ refactor : 코드 리팩토링
# 💄 design : CSS 등 사용자 UI 디자인 변경
# 💡 comment : 필요한 주석 추가 및 변경
# 🎨 style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
# 🧪 test : 테스트 코드, 리팩토링 테스트 코드 추가
# 🛠 chore : 빌드 업무 수정, 패키지 매니저 수정
# 🎉 init : 프로젝트 초기 생성
# 🚚 rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 수행한 경우
# 🔥 remove : 파일을 삭제하는 작업만 수행한 경우

😻GitHub 템플릿 세팅

GitHub issue 템플릿 세팅

---
name: 이슈 생성 템플릿
about: 문제가 발생하였을 경우 해당 템플릿을 사용하여 이슈를 생성합니다.
title: ''
labels: ''
assignees: ''

---

## 📝 어떤 문제가 발생했나요?
> 문제를 간결하게 설명해주세요
## 📢 어떤 상황에 발생했나요?
> 상황을 설명해주세요
## 💊 예상 결과
> 문제를 해결했을 경우 예상되는 결과를 적어주세요

GitHub pull_request 템플릿 세팅

## 😀 제목 :

<br/>

## 🔎 작업 내용

- 어떤 변경 사항이 있었나요?

- [ ] 새로운 기능 추가
- [ ] 버그 수정
- [ ] CSS 등 사용자 UI 디자인 변경
- [ ] 코드에 영향을 주지 않는 변경사항(오타 수정, 탭 사이즈 변경, 변수명 변경)
- [ ] 코드 리팩토링
- [ ] 주석 추가 및 수정
- [ ] 문서 수정
- [ ] 테스트 추가, 테스트 리팩토링
- [ ] 빌드 부분 혹은 패키지 매니저 수정
- [ ] 파일 혹은 폴더명 수정
- [ ] 파일 혹은 폴더 삭제

<br/>

## 🎨 이미지 첨부

<br/>

## 🔧 앞으로의 과제

- 다음으로 할 일은 무엇인가요??

  <br/>

## ➕ 추가 코멘트

<br/>

GitHub 가이드라인 세팅

# 기여 가이드라인

카카오 엔터프라이즈 5기 먀옹팀의 포폴로그 프론트엔드 레포지토리입니다.
다음 가이드라인을 따라주시기 바랍니다.

## 이슈 보고하기

- 이슈를 보고하기 전에 이미 보고된 이슈인지 확인해주세요.
- 명확하고 설명적인 제목을 사용해주세요.
- 가능한 한 많은 관련 정보를 포함해주세요.

## 풀 리퀘스트 제출하기

1. 새로운 브랜치를 만드세요: `git checkout -b my-new-feature`
2. 변경사항을 커밋 컨벤션에 맞춰 add 후 커밋하세요: `git commit -m 'Add some feature'`
3. 브랜치에 푸시하세요: `git push origin my-new-feature`
4. 깃 허브에서 풀 리퀘스트를 제출하세요.
5. 코드 리뷰 요청 후 main 브랜치에 머지합니다.

## 코딩 컨벤션

- camelCase를 사용합니다.
- 상수의 경우 대문자 snake_case를 사용합니다.
- 컴포넌트명은 PascalCase를 사용합니다.
- 폴더명(페이지명)은 소문자로 시작하고 필요에 따라 하이픈을 사용합니다.
- 아이콘은 ic-파일명.ts로 public 폴더에 하나의 파일에서 관리합니다.
- 주석은 코드 위에 작성합니다.

감사합니다!

해당 가이드라인을 따라 이슈 생성, 혹은 풀리퀘스트 생성을 진행할 수 있습니다.

김현중

진짜 성실한 사람

다음 포스트

[PPLOG] 프로젝트 프론트엔드 세팅하기

PPLOG

💀Next.js 14 세팅

Next.js란 무엇인가?

세팅하기

Next.js 14를 사용한 이유

TypeScript를 사용한 이유

📝ESLint 세팅

ESLint란 무엇인가?

세팅하기

Airbnb ESLint 스타일을 사용한 이유

🐺Husky 세팅

Husky란 무엇인가?

ESLint와의 차이점

세팅하기

Husky를 사용해 커밋 메시지 검사 추가

😻GitHub 템플릿 세팅

GitHub issue 템플릿 세팅

GitHub pull_request 템플릿 세팅

GitHub 가이드라인 세팅

[PPLOG] Axios 세팅하기

0개의 댓글