[spotify-api] VINYLIFY : 스포티파이 api활용한 검색 + 재생 프로젝트(4) eslint + prettier + commitlint 설정 (+husky)

2024.06.12 - [👩🏻‍💻 dev] - [spotify-api] VINYLIFY : 스포티파이 api활용한 검색 + 재생 프로젝트(3) 준비물: authorization을 담당할 서버 코드

[spotify-api] VINYLIFY : 스포티파이 api활용한 검색 + 재생 프로젝트(3) 준비물: authorization을 담당할 서

사용할 spotify api에 대한 준비가 끝났으니 이제 본격적으로 프로젝트 설정을 해보자.
오늘은 eslint와 prettier가 각각 뭔지, 왜 필요한지 그리고 설정 방법에 대해 살펴보자.
그리고 커밋 메시지가 린트가 되도록 commitlint 도 설정해 주자. 

⚠️ 해당 프로젝트는 vite+react+yarn을 기준으로 다룹니다! 모든 설정 파일들은 root에 생성합니다.

Prettier

[출처] https://prettier.io/

🤔 prettier가 뭐고 왜 필요할까?

prettier의 공식 페이지에 들어가면 prettier는 "opinionated" 코드 포멧터라고 소개한다.

prettier가 opinionated(prettier가 정립한 스타일을 고수하는) 이유는 코딩 스타일에 대한 논쟁을 멈추기 위해서라고 한다.

스타일에 대한 옵션이 생기면 "어떤 옵션이 더 좋은가?", "왜?", "우리가 한 선택이 최선인가?"라는 논쟁이 발생한다. 코드 리뷰 때 일일이 "여기는 작은따옴표로 쓰셨네요, 큰 따옴표로 모두 변경해 주세요."라는 말을 듣거나 하는 게 정말 필요한 과정일까 싶다. 코드를 짜기도 전에 이런 논쟁들을 하다보면 정말 중요한 코드 짜기에 쓰는 에너지를 낭비하는 일뿐이다. 

 

다른 스타일 가이드을 두고 왜 prettier를 사용해야 싶겠지만, prettier에게는 100% 완전한 자동화라는 최강의 무기가 있다.

분명 prettier가 정한 코드 포맷팅 중에 마음에 쏙들지 않는 부분도 있기 마련이지만 하나의 스타일로 자동으로 통일해 주는 이점과 저장으로 바로 포맷이 적용되는 이점이 더 매력적으로 다가온다. 

저장시 자동 포멧팅

 

prettier는 일관성있는 코드 스타일로 포맷을 해주는 도구라는 점을 알게 되었다.

이제 사용하는 방법에 대해 알아보자. 먼저 prettier 설정에 대해 살펴보고, 그 후 git hooks 설정도 추가해 보자.

prettier 설정

1. 설치

yarn add --dev --exact prettier

 

2. 설정 파일

• . prettierrc 파일을 만들고, 오버라이드 하고자 하는 규칙이 있다면 여기에 적으면 된다.

{
  "singleQuote": true,
  "trailingComma": "all",
  "arrowParens": "avoid"
}

• .prettierignore 파일을 만들고, 포맷을 하고 싶지 않은 파일들을 추가해 주면 된다.

# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.

# dependencies
/node_modules
/.pnp
.pnp.js

# testing
/coverage

# next.js
.next
/.next/
/out/

# production
/build

# misc
.DS_Store
*.pem

# debug
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# local env files
.env.local
.env.development.local
.env.test.local
.env.production.local

# changelog
CHANGELOG.md

Git hooks 설정

1. 설치

yarn add --dev husky lint-staged
npx husky init

 

2. 설정 파일

• .husky/pre-commit 파일을 생성하고 아래의 명령어를 추가한다.

npx lint-staged

• package.json에 아래와 같이 추가를 해준다.

{
  "lint-staged": {
    "**/*": "prettier --write --ignore-unknown"
  }
}

실행

터미널에 yarn prettier . --write 명령어로 실행해 보자.

(...생략...)

 

해당 명령어로 항상 실행하는 번거로움을 느꼈을 수도 있다. package.json scripts에 명령어로 실행할 수 있도록 추가해 보자.

{
  "name": "vinylify",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview",
    "prepare": "husky",
    "format": "yarn prettier . --write", // 추가
    "format:check": "yarn prettier . --check", // 추가
    "typecheck": "tsc --noEmit --incremental false"
  },
// ... 생략
}

---

Eslint

🤔 eslint가 뭐고 왜 필요할까?

Eslint는 ECMAScript와 JavaScript 코드를 정적으로 분석해서

코드 에러를 찾아줘서 코드 퀄리티가 일정하고 버그를 피할 수 있도록 하는 도구다.

eslint 설정

1. 설치

yarn create @eslint/config@latest

 

2. 설정

yarn init @eslint/config

 

위의 명령어를 입력하면 eslint.config.js 나 eslint.config.mjs 등의 파일이 생성된다.

그 안에는 규칙을 설정해 줄 수 있다.

 

예를 들면, 다음과 같이 "off"는 규칙을 끄고, "warn" 또는 1로 설정 시 경고만 켜고 exit code는 영향을 주지 않고, "error" 또는 2로 설정하면 에러를 키고 exit code를 1로 설정하는 것이다.

// eslint.config.js
import js from "@eslint/js";

export default [
    js.configs.recommended,

    {
        rules: {
            "no-unused-vars": "warn",
            "no-undef": "warn"
        }
    }
];

 

eslint의 큰 특징은 적용할 규칙들을 플러그인 할 수 있다는 것이다.

원하는 설정들을 devDependencies로 추가하고 config 파일에도 추가를 해주자.

yarn add @typescript-eslint/parser eslint-plugin-react-hooks eslint-plugin-react-refresh

module.exports = {
  root: true,
  env: { browser: true, es2020: true },
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:react-hooks/recommended',
  ],
  ignorePatterns: ['dist', '.eslintrc.cjs'],
  parser: '@typescript-eslint/parser',
  plugins: ['react-refresh'],
  rules: {
    'react-refresh/only-export-components': [
      'warn',
      { allowConstantExport: true },
    ],
  },
};

Prettier vs. Linters

prettier와 eslint는 포맷을 해주는 도구라는 건 같은데, 담당 영역이 서로 다르다는 걸 알 수 있다.

linter는 다음의 두 카테고리로 규칙을 나눌 수 있다.

 

포멧 규칙 : eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style… 

 

prettier는 이렇게 다양한 규칙들에 대한 고민을 한방에 없애준다.

우리가 어떻게 코드를 짜던간에 prettier는 자신의 포맷 규칙으로 코드를 새로 포맷해 주기 때문이다.

 

코드 퀄리티 규칙: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors…

 

prettier는 코드 퀄리티에 관여하지 않는다. 

이 일은 linter (eslint, tslint, stylelint 등)이 담당할 영역이라는 것이다.

코드에 있는 버그들을 잡는 역할은 linter가, 코드 외관(?)을 일관되게 꾸며주는 역할은 prettier가 담당한다는 차이가 있다.

---

Commitlint

 

마지막으로 commitlint를 설정해 주자.

commitlint는 커밋 컨벤션을 준수하도록 도와주는 린터다.

설치

yarn add --dev @commitlint/{cli,config-conventional}

설정

• commitlint.config.js 파일을 생성하고, 설정을 추가해 보자.
  • 아래의 설정은 커밋 메시지 작성 시 배열 안의 키워드로 시작해야 한다는 규칙이다.

export default {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'feat',
        'fix',
        'docs',
        'chore',
        'style',
        'refactor',
        'ci',
        'test',
        'perf',
        'revert',
        'init',
      ],
    ],
  },
};

 

이제 커밋 메시지 작성할 경우 자동으로 린트를 해줄 설정을 추가해 보자.

• github/workflows/commitlint.yml 파일 생성

name: Lint Commit Messages
on: [pull_request, push]

jobs:
  commitlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: wagoid/commitlint-github-action@v4

 

• .husky/_/commit-msg 파일에 아래의 내용 추가

npx --no -- commitlint --edit $1

 

실행

커밋 키워드 없이 커밋 메시지 작성 시 에러가 발생한다.

---

👩🏻‍💻 오늘은 코드를 본격적으로 짜기 전 코드 포맷에 대한 설정을 모두 했다.
코드 스타일, 코드 버그 분석, 커밋 메시지 린트 등의 규칙을 논하려면 많은 에너지가 쓰일 수 있다.
하지만 미리 약속한 규칙을 정하고, 자동화까지 가능한 도구들을 도입해 이런 논쟁으로 쓰일 에너지를 절약해서
더 효율적으로 작업을 진행할 수 있기에 개발자 경험 (DX)를 높일 수 있다.

🍀 오늘은 적용한 거를 기록해 보니 각 도구들을 더 살펴볼 기회가 된 거 같아서 흥미로웠다. 

📚 References 

https://prettier.io/docs/en/comparison

Prettier · Opinionated Code Formatter

https://eslint.org/

Find and fix problems in your JavaScript code - ESLint - Pluggable JavaScript Linter

https://commitlint.js.org/

commitlint