서론
팀 프로젝트로 협업하면서 코드 스타일을 통일하기 위해 주로 사용하는 것이 ESLint와 Prettier다.
이미 프로젝트 시작전에 설정은 해뒀지만, 추가로 필요한게 몇가지 있는 것 같아서 Prettier와 ESLint를 건드리다가 여유가 있을 때 제대로 좀 알아보려한다.
설치같은 경우 이미 많은 글과 공식문서에서도 확인할 수 있기 때문에 따로 서술하지는 않을 것이다.
ESLint
먼저 ESLint를 사용하는 이유가 뭘까?
인터프리터 언어인 자바스크립트는 코드를 실행하기 전에 컴파일 단계가 없기 때문에 컴파일러가 오류를 검출할 수 없다. 즉, 런타임에서만 오류가 발생한다는 뜻이다.
하지만 "우리가 사용하는 Webpack이나 Vite를 사용하면 자바스크립트 파일을 컴파일을 하지 않나?" 라고 생각할 수 있는데, 이러한 도구들을 사용해도 여전히 자바스크립트는 인터프리터로 동작한다. Vite나 Webpack을 사용해서 번들링, 컴파일하는 것은 코드를 최적화하고 브라우저에서 실행을 더 효율적으로 하기 위한 과정일 뿐이기 때문이다.
Lint & Linter
Lint는 정적 코드 분석 도구로, 코드에 존재하는 오류, 스타일 가이드 위반 등을 감지하는데 사용된다.
Linter는 Lint 도구를 지칭하는 용어다.
그래서 우리는 컴파일 단계에서 오류를 잡아내기 위해 ESLint를 사용한다. 하지만 우리는 코드를 작성할때 오류를 잡아주는 것을 원하기 때문에 VSCode에서는 코드 작성중에 오류를 잡아줄 수 있게 도와주는 ESLint 익스텐션을 제공한다.
이 ESLint 익스텐션은 우리가 작성한 프로젝트 루트 디렉토리에 존재하는 ESLint 설정 파일을 기반으로 동작한다. 익스텐션은 지속적으로 파이프라인을 통해 우리가 만든 설정파일과 내장된 ESLint를 기반으로 Lint를 실행하여 우리의 코드에서 오류를 잡아낸다.
Prettier
Prettier는 ESLint와 달리 그리 복잡하지 않다. 그저 코드 포맷팅 도구로 코드의 스타일을 일관되게 유지하는 것을 도와준다.
Prettier는 컴파일할때 자동으로 실행되지 않는다. 우리가 IDE에 설정해주어야 특정 시점에 동작한다. 우리는 보통 VSCode에서 파일을 저장할때 실행되도록 설정했을 것이다.
협업을 하면 각자 코드의 스타일이 다르기 때문에 이를 일관되게 유지하기 위해서 사용하는데, 아마 팀 프로젝트를 해보았다면 필요성을 느낄 것이다.
Prettier 규칙 설정
플러그인을 받아서 사용할 수도 있지만, 직접 설정하는 경우도 적지 않다. 본인의 경우 직접 설정하는 편이다.
규칙이 뭐가 있나 하나하나 검색할 수 있지만 이러면 너무 귀찮으니까 공식문서로 들어가보자.
공식문서에 들어가면 TRY IT ONLINE 버튼이 있다. 이 버튼을 누르면 편리하게 인터페이스를 통해서 설정을 쉽게 바꾸고 그 결과를 눈으로 확인할 수 있다.
원하는 설정이 끝났다면 아래에 Copy config JSON 버튼을 클릭하면 현재 설정을 복사해서 가져올 수 있다.
만약 설정을 바꿔도 코드에 변화가 보이지 않는다면 해당 규칙에 대한 코드가 없어서 그럴 수 있다. 규칙에 대한 코드를 작성할 수도 있는데, 그냥 GPT에 물어보면 무슨 규칙인지 쉽게 알려준다.
직접 설정하지 않아도 다양한 Prettier 플러그인이 있어서 간단하게 포맷팅 규칙을 설정할 수 있다.
마무리
ESLint 설정에 대해서는 공식문서나 스택오버플로우를 참고하는 것을 추천한다. 본인의 지식으로 서술해봤자 공식문서보다 못할 것이다...😂
그래도 왜 사용하는지 언제 어떻게 동작하는지에 대해서 아는 것이 더 중요하다고 생각한다.
아래 참고글에서 eslint-plugin-prettier를 사용하지 말자는 이야기가 있는데, 한번씩 읽어보는 것을 추천한다. 해당 플러그인의 메인테이너도 오래전부터 사용하지 않는다고 한다.
