Prettier를 ESLint "--fix"로 대신 사용할 수 있을까? v1.0

Prettier를 ESLint "--fix"로 대신 사용할 수 있을까?

ESLint의 역할
1. Code Qualify: 코드를 정적으로 분석하여, 잠정적으로 문제가 될 수 있는 부분을 빠르게 찾도록 도와주는 것
2. Code Formatter: 의미대로 보자면, 정한 규칙에 맞춰 코드를 조정해주는 것

Prettier의 역할
1. Code Qualify: 지원하지 않는, 정확하게 지원 대상이 아님
2. Code Formatter(Reformatter): 코드를 원하는 형태로 재정렬 해주는 것

차이점
Code를 형태를 정렬하는 것과 오류를 보정하는 것은, 그다지 차이나는 것이 아닌 것으로 보일 수 있지만, 실제는 큰 차이가 있다.
ESLint는 Code Qualify 규칙(.eslintrc 등)에 따라 그 코드에 대한 조정 혹은 경고를 하는 것(흔히 코드의 품질을 높이기 위한 목적으로 적용)인데,

Prettier는 reformatter이기 때문에, 문법적 오류에 대한 접근 없이, 코드를 형식을 변경한다.

ESLint 예제를 기반으로 설명하겠다. 가능한 최대한 같은 조건을 시험하기 위해서, 옵션을 서로 맞췄다. (옵션 자체를 일일이 비교하는 것이 아니므로, 그 각각의 세세한 차이는 고려하지 않는다. 모든 값을 설정하면, 거의 같은 형태의 모양을 구현할 수는 있다.)

ESLint 예제에 약간의 내용을 추가했다.

원본,
var loooong = 'abcdefghijklmnopqrstuvwxyz`1234567890~!@#$%^&*()_+[]\;,./{}|:<>?가나라다마사바사';;

const abc = 'abc"def"ghi';
const def = "abc'def'ghi";
const ghi = "abc`def`ghi";
const stu = `abc"def"ghi`;
const xyz = `abc'def'ghi`;

function addOne(i) {
  switch (i) {
     case 1:
      break;
  }
    if (i != NaN) {
        return i ++
    } else {
      return
    }
};

Prettier를 수행했을 때,
var loooong =
  "abcdefghijklmnopqrstuvwxyz`1234567890~!@#$%^&*()_+[];,./{}|:<>?가나라다마사바사";

const abc = 'abc"def"ghi';
const def = "abc'def'ghi";
const ghi = "abc`def`ghi";
const stu = `abc"def"ghi`;
const xyz = `abc'def'ghi`;

function addOne(i) {
  switch (i) {
    case 1:
      break;
  }
  if (i != NaN) {
    return i++;
  } else {
    return;
  }
}

원래 작성했던 형식에서, 사용자가 미리 정해놓은 규칙대로 변해있는 것(reformat)을 볼 수 있다.

장점, 코드의 모양을 통일하여, 여럿이 작성해도 마치 한사람이 작성-typing-한 것 같은 느낌을 준다. 공동 작업에 도움이 될 수 있는 부분이다.
단점, 코드의 모양에 개성이 없어지고, 누구에게는 가독성이 증가하지만, 누구는 가독성이 떨어질 수 있다.

ESLint를 수행했을 때,
const loooong = "abcdefghijklmnopqrstuvwxyz`1234567890~!@#$%^&*()_+[]\;,./{}|:<>?가나라다마사바사";

const abc = "abc\"def\"ghi";
const def = "abc'def'ghi";
const ghi = "abc`def`ghi";
const stu = "abc\"def\"ghi";
const xyz = "abc'def'ghi";

function addOne(i) {
  switch (i) {
     case 1:
      break;
  }
  if (i != NaN) {
    return i++;
  }
}

Reformat 뿐만 아니라, 코드의 작성 의도도 사용자가 미리 정해놓은 규칙대로 변해있는 것을 볼 수 있다. (원한다면, 이 옵션을 조정하여, 처리되지 않도록 할 순 있다.)
이는 작성된 코드가 앞으로 발생될 수 있는 혹은, 예상되지 못한 문제-옳고 그름이 아닌-대응으로써 수정된 것이다.

장점,  Prettier의 장점과 동일하다. 게다가 문법적 오류 뿐 아니라, 잠정적으로 발생할 수 있는 여러 문제에 대한 점검 혹은 조정을 할 수 있다.
단점, 코드의 모양에 개성이 없어지고, 누구에게는 가독성이 증가하지만, 누구는 가독성이 떨어질 수 있다. 또한, "max-len"에 대한 처리 (실제 줄 보정안함) 및 지정되지 않은 형식은 수정하지 않는 문제가 있다.
그리고, 코드의 형식 뿐만 아니라 내용도 바꿔버리기 때문에, 작성자가 자신의 코드가 어떤 의미로 바뀌었는지 다시한번 확인해야 한다.

Prettier vs ESLint --fix를 원본과 비교한 모습

결론
팀원 모두 동일한 모양의 코드를 채용하여, 통일된 코드 형식을 정할 때는, Prettier로 하고, 이를 ESLint --fix를 처리하면, 좀 더 통일된 작성 형식을 구축할 수 있을 것이다.
그러나, 필자는 작성된 코드의 과도한 변경은 기존 작성 과정에 혼동을 주게 될 우려가 있음으로 작성 단계에서, ESLint의 경고에 맞춰 작성을 하고, reformat은 Prettier의 도움을 받은 것이 더 안정된 작업 과정이 아닐까 생각한다.
또한, 상호 충돌하는 옵션이 많이 때문에, 그에 대한 보정도 필요하다.

적용 추천
ESLint의 plug-in으로 Prettier를 연동하여 작성하는 것이 상호 보완체로서 좋은 선택이 아닐까 싶다.
또한, IDE (Intellij, WebStorm, Visual Studio Code)를 사용할 때, 자체 Plugin 혹은, 설정의 reformatter를 사용하지 않는 것이 좋다.
그리고, format-on-save 혹은 file-watcher로 해당 부분을 적용해 사용하는 것도 편리하다.

댓글

이 블로그의 인기 게시물

Next.js에서 자연스러운 Page Transition 방법

[flutter] Android - Package간 sdk version 등이 맞지 않아 오류가 발생하는 경우

[Windows] Chocolatey upgrade