ESLint 적용기
배경
프로젝트 초기에는 ESLint가 무엇인지 정확히 몰랐다. 그냥 기본적으로 설정해야 하는 거라 큰 의미 없이 셋업을 했기 때문이다. 결과적으로 ESLint를 제대로 활용하지 못하고 있었다. eslint --fix --ext .js,.jsx,.ts,.tsx. 명령어를 실행해도 플러그인이 설치되어 있지 않아 린트의 룰을 적용할 수 없는 상태였다.
Prettier의 필요성에 대한 의문
다행히 프로젝트 내에는 Prettier가 설정되어 있어 코드가 나름 규칙을 갖추고 있었다. Prettier 역시 사람들이 사용하니까 이유를 모른 채 적용했는데, 코드가 보기 좋게 정렬되는 것이 좋다는 정도로만 활용했다. 협업을 하지 않는 단독 프로젝트라 Prettier를 제거했다. Prettier의 경우 Lint와 역할은 명백히 다르지만, Lint의 --fix 옵션이 있는데 굳이 Prettier가 필요할까에 대한 의문이 생겼다.
Lint와 Prettier의 차이점
Prettier는 코드 스타일을 일관되게 유지하는 데 중점을 두며, 코드 포매팅에 특화되어 있다. 반면 ESLint는 코드의 품질을 유지하고 잠재적인 오류를 방지하는 데 중점을 둔다. ESLint의 --fix 옵션은 일부 포매팅 문제를 해결할 수 있지만, Prettier만큼 강력하고 일관된 포매팅을 제공하지는 않는다. 따라서 협업 프로젝트에서는 두 도구가 서로 보완적인 역할을 하지만, 단독 프로젝트에서는 ESLint만으로도 충분할 수 있다.
한눈에 보이는 코드의 비일관성 문제
어떤 경우에는 싱글 쿼터를 사용하고 어떤 경우는 더블 쿼터를 사용하는 등, 컴포넌트 선언 시 어떤 경우는 일반 함수를, 어떤 경우는 화살표 함수를 이용하는 규칙적이지 못한 코드가 많았다. 이러한 부분을 수정하고, 코드 작성 시 프로젝트의 오류를 최소화하기 위해 ESLint를 재설정했다. 기본 ESLint 룰을 AirBnB 스타일로 교체하고, 메가테라에서 전수받았던 lint 룰을 적용했다. 첫 fix 결과 340개의 에러가 발생했다.
주요 문제점들
- import React, { useState }와 같은 리액트 선언 문제.
- 리액트 키를 idx로 사용하는 문제.
- button에 타입을 명시하지 않은 경우.
- 컴포넌트 내부에서 컴포넌트 함수를 반환하는 경우.
7일간 340개의 에러를 수정하고 빌드를 하는 과정을 거치면서, 그동안 프로젝트에 잠재적인 문제가 많았음을 반성하게 되었다. 앞으로는 ESLint를 적용하여 최소한의 오류라도 방지하고 코드 스타일을 유지하겠다고 다짐하게 되었다
최종 결과
이제 프로젝트는 ESLint를 통해 일관된 코드 스타일과 규칙을 유지할 수 있게 되었다. 초기 설정의 중요성과 이를 통해 프로젝트의 품질을 향상시킬 수 있음을 깨닫게 되었다.
발생한 이슈
모듈 간 의존성 문제
AirBnB 스타일의 룰 중에서 모듈 간의 의존성이 엮이는 문제를 많이 겪었다. 그 원인은 백엔드 API와 밀접한 연관이 있는 타입의 경우 types 폴더에 따로 정리하여 재사용성을 높이고 분리하였지만, 일반적으로 컴포넌트에서만 필요한 경우는 최상단에 배치했기 때문이다. 이 과정에서 커스텀 훅을 사용하다 보면 해당 컴포넌트의 타입이 필요한 경우가 있어 타입을 재활용했는데, 이것이 가장 큰 문제였다. 이렇게 하면 서로 모듈 간의 의존성이 엮여 해당 컴포넌트가 커스텀 훅을 사용하는 중에 커스텀 훅은 컴포넌트의 타입을 참조하기에 의존성이 서로 엮이는 문제가 발생했다. 앞으로 재사용 타입이나 모듈의 경우는 외부로 분리해주어야겠다고 다짐했다. 이 부분은 import/no-cycle 규칙에서 발생하는 것이다.
