본문으로 바로가기

프론트엔드 개발환경의 이해 : prettier

category Frontend 2021. 4. 8. 22:24

Prettier

ESLint는 두 가지를 검사한다고 했다

코드의 가독성을 높여주는 포매팅 단계, 코드가 실행될 때 오류가 될 수 있는 부분을 코드 품질 단계에서 검수하는데

prettier는 ESLint의 포매팅 단계의 역할만을 수행하는 대신, 좀 더 강력한 기능을 제공한다

설치 및 사용

npm i -D prettier

이제 prettier를 어떻게 사용하고 어떻게 적용되는지 알아보자

//app.js
console.log()

npx prettier app.js로 실행하면

sample % npx prettier app.js        
console.log();

수정되어 세미콜론을 적용한 결과물을 보여준다

eslint의 --fix 옵션처럼 결과물을 보여주는 것 말고 파일 자체를 수정하는 옵션도 줄 수 있는데

npx prettier app.js --write로 실행시키면 app.js 파일이 수정된다

차이점

위만 봐선 왜 pritter를 써야하는지, 무엇이 더 강력하다고 하는지 잘 모르겠다

다음과 같은 코드를 보자

foo(reallyLongArg(),    omgSoManyParameters(),    IShouldRefactorThis(),    isThereSeriouslyAnotherOne())

코드 자체엔 별 문제가 없지만 너무 길고 한 눈에 보이지 않는, 가독성이 떨어지는 불편함이 있다

이를 eslint로 돌리면 아무 사항도 수정해주지 않지만 pritter를 사용하면

foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne()
);

이처럼 코드의 문맥을 파악하고 사용자가 읽기 쉽게 바꾸어준다

통합하기

설정 끄기

이처럼 ESLint보다 더 나은 포매팅인 prettier만 사용할 수 없는 이유는 코드 품질 관리에 있다

prettier는 포매팅만 정정해주고 코드 품질에 관한 부분은 손을 대지 않기 때문

그래서 이 두 가지 라이브러리를 같이 사용해주어야하는데 그러기 위해선 ESLint의 포매팅, prettier의 포매팅이 겹치는 부분을 방지해야한다

eslint-config-prettier를 설치해서 extends 설정에 추가해주면 prettier와 겹치는 부분은 ESLint에서 관여하지 않는다

이제 ESLint와 prettier을 동시에 돌리면 prettier는 포매팅만, ESLint는 코드 품질만 관리한다

npx prettier app.js --write && npx eslint app.js --fix

매번 이렇게 두 가지를 동시에 실행시켜주어야하는 것 또한 번거러운 일

합치기

ESLint의 포매팅 규칙을 prettier와 동일한 규칙으로 바꾸어주는 플러그인이 존재하낟

eslint-plugin-prettier를 설치해서 플러그인과 규칙을 설정해주자

module.exports = {
    plugins: [
        "prettier"
    ],
    rules: {
        "prettier/prettier": "error"
    }
}

이렇게 하면 이제 ESLint는 prettier와 완전히 동일한 포매팅을 수행하게된다

최종적으로 다음과 같은 설정 파일을 가지게 된다

module.exports = {
    "extends": [
        "eslint:recommended",
        "plugin:prettier/recommended"
    ]
}

자동화

이러한 검사들은 코드를 작성할 때마다 수시로 해주어야하는데 개발자가 하면 피곤하니까 자동으로 검사하게끔 하는 것이 생산성을 높혀준다

자동화 방법에는 두 가지가 있다 깃 훅을 이용하는 방법, 에디터에 플러그인을 추가하는 방법

깃 훅

깃에는 커밋이나 푸쉬, 커맨드 명령 실행되기 직전 시점에 끼어들 수 있는 훅을 제공한다

바로 husky인데 설치 후에 package.json 파일에 다음과 같이 작성해주자

...
  "husky": {
    "hooks": {
      "pre-commit": "echo \"이것은 커밋전에 출력됨\""
    }
  }
...

이렇게 해두면 husky가 commit 명렁어가 실행되기 전 시점에 다음과 같은 문자열을 출력해준다

% git commit --allow-empty -m "빈 커밋"

husky > pre-commit (node v14.16.1)
이것은 커밋전에 출력됨
[3-lint/2-prettier 18741a2] 빈 커밋

이렇게 커밋전에 끼어들 수 있다는 점을 활용해서 린트 명령어를 넣어주면

...
  "husky": {
    "hooks": {
      "pre-commit": "eslint app.js --fix"
    }
  }
...

커밋할 때 eslint가 돌게되고 결과값으로 error를 반환한다면 커밋이 취소된다

이제 에러 메시지를 보고 코드를 수정한 후에 커밋을 날려주면되는 것 그렇게 함으로 코드는 일관된 스타일을 유지할 수 있다

lint-staged

커밋할 코드의 양이 많아지면 많아질 수록 eslint가 검사해야할 코드도 많아지게 되고 그에 따라서 커밋 작성이 느려지는 것은 당연한 결과처럼 보인다

그래서 커밋시에 이전 커밋과 바뀐 점이 있는 파일만 검사하는 도구를 추가해주자

npm i -D lint-staged

...
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
  "lint-staged": {
    "*.js": "eslint app.js --fix"
  }
...

이제 변경된 js파일만을 대상으로 eslint를 수행한다

에디터 익스텐션

vs-code, atom, intelliJ 등 각각의 에디터들에서 pritter를 익스텐션으로 제공하니 받아서 사용하면 된다