road: ESLint에서 Prettier를 검사해도 괜찮을까?

roads/2024/06/05.mdx

@@ -0,0 +1,72 @@
+---
+title: 'ESLint에서 Prettier를 검사해도 괜찮을까?'
+date: '2024-06-05'
+slug: '2024-06-05'
+type: 'road'
+---
+
+## 정원 가꾸기
+
+프로젝트의 **안정성, 품질, 일관성**을 높이기 위해 린트 및 자동화와 관련된 작업을 진행했다.
+
+일차적인 목표는 PR 단계에서 `Github Actions`를 활용해서 `ESLint`, `Prettier`, `tsc` 관련 명령어를 실행하는 것이다.
+
+이 과정에서 배운 내용을 정리하고자 한다.
+
+## ESLint에 Prettier도 포함하면 안되는건가?
+
+> `ESLint`에서 `Prettier`도 검사하면 괜찮지 않을까?
+
+작업 내용을 팀원들에게 공유했을 때 위와 같은 의견이 나왔다.
+
+이 의견을 듣고 어렴풋이 접했던 `eslint-plugin-prettier`, `eslint-config-prettier`가 떠올랐다.
+
+그래서 동일한 환경으로 빠르게 테스트를 진행해봤다.
+
+<br />
+
+- `eslint-plugin-prettier`: `ESLint` 규칙처럼 `Prettier` 실행해서 `ESLint` 이슈로 보고
+- `eslint-config-prettier`: 불필요하거나 `Prettier`와 충돌할 수 있는 규칙 비활성화
+
+<br />
+
+`.eslintrc` 파일에는 `plugin:prettier/recommended`을 추가해준다.
+
+**.eslintrc**
+
+```js
+{
+  "extends": ["plugin:prettier/recommended"]
+}
+```
+
+이때 이 플러그인은 확장 배열의 마지막에 위치하도록 해야 한다.
+
+<br />
+
+이렇게 하면 `prettier --check`와 동일하게 `ESLint` 환경에서 `Prettier` 검사가 가능해진다.
+
+## 통합시키는게 바람직한 방향일까?
+
+하지만 작업을 진행하며 관련 문서를 읽고 학습하면서 `ESLint`와 `Prettier`를 분리해서 접근하는 것이 좋게 느껴졌다.
+
+이유는 다음과 같다.
+
+<br />
+
+- 기존 `prettier --check .` 명령어로도 해결이 가능하다.
+- `Prettier` 직접 실행하는 것보다 느리다. 포맷팅 또한 에러로 표시되게 된다.
+- `ESLint` 팀에서도 포맷팅 규칙에 대한 지원을 중지한다고 발표했다.
+- `Prettier`는 포맷팅에, `Linter`는 코드 퀄리티에 집중하는 것을 권장한다.
+
+## 결론
+
+`ESLint`와 `Prettier`는 분리해서 접근하자!
+
+프로젝트에서도 다시 원래 방식대로 `ESLint`, `Prettier`를 구분해서 실행하는 걸로 정해졌다. 🧐
+
+### 참고 문서
+
+- [Integrating with Linters](https://prettier.io/docs/en/integrating-with-linters)
+- [Deprecation of formatting rules](https://eslint.org/blog/2023/10/deprecating-formatting-rules/)
+- [Prettier vs. Linters](https://prettier.io/docs/en/comparison)