[번역] 포맷팅 규칙이 ESLint에서 사라집니다

ESLint 블로그 원문(Deprecation of formatting rules)을 한국어로 번역한 글입니다.

다음 ESLint 마이너 버전에서 핵심적인 포맷팅 규칙들이 폐기(deprecate)될 예정입니다. 대신 소스 코드 포맷터를 사용하시기를 권장드립니다.

2023년 11월 3일 금요일에 릴리즈 예정인 ESLint 8.53.0 버전에서 포맷팅 규칙이 공식적으로 폐기됩니다. 포맷팅 규칙은 띄어쓰기, 세미콜론, 문자열 형식 등을 아우르는 코드 컨벤션을 강화시켜 주는 규칙을 의미합니다. 이 글에서 설명할 여러 가지 이유로 인해 폐기되며 이는 ESLint를 위한 올바른 결정이라고 생각합니다. 하지만 이 결정을 이해하기 위해서 지금까지의 과정을 돌아보는 것이 도움이 됩니다.

배경

2013년 ESLint가 처음 릴리즈되었을 때, 자바스크립트 생태계에서는 소스 코드 포맷팅을 린터에 포함시켜야 하는지에 대한 논쟁이 활발했습니다. 오리지널 자바스크립트 린터였던 JSLint는 코드 작성자의 포맷팅 기본 설정을 너무 많이 인코딩했습니다. 이러한 기본 설정은 JSLint의 후속 버전인 JSHint로 이어지면서 어느 정도 완화되었지만, 2013년에 JSHint는 포맷팅 옵션을 더 이상 사용하지 않으며 다음 메이저 릴리즈에서 폐기할 예정이라고 발표했습니다. 옵션이 완전히 제거되지는 않았지만 여전히 다음과 같은 경고가 표시됩니다

경고 이 옵션은 더 이상 사용되지 않으며 JSHint의 다음 메이저 버전에서 제거될 예정입니다.

JSHint는 코드 정확성 문제로 범위를 제한하고 있습니다. 코드 스타일에 대한 규칙을 적용하려면 JSCS 프로젝트를 확인하세요.

JSCS 프로젝트는 자바스크립트 개발자들이 보다 구체적인 방식으로 코드의 포맷을 지정하고자 하는 욕구를 충족시키기 위해 탄생했습니다. ESLint와 같은 해에 등장한 이 프로젝트는 사람들이 린팅 및 포맷팅 요구 사항을 충족하기 위해 JSHint, JSCS, ESLint의 다양한 조합을 시도하면서 약간의 실험 기간을 거쳤습니다.

초기에 저는 ESLint가 JSHint와 합리적으로 경쟁할 수 있는 유일한 방법은 사용 가능한 모든 JSHint 규칙에 ESLint와 동등한 규칙이 포함되도록 하는 것이라고 생각했습니다. ESLint의 강점은 사용자 정의 규칙을 만드는 것이었지만(지금도 동일하지만), 모든 사람이 JSHint 규칙을 직접 다시 만들어야 한다면 ESLint가 많이 채택되지는 않을 것이라고 생각했습니다. 초기 계획은 수십 개의 핵심 규칙만 만들고 나머지는 플러그인으로 구현하도록 남겨두는 것이었습니다.

시간이 지남에 따라 핵심 규칙에 포맷팅 및 스타일 규칙을 추가해 달라는 요청이 점점 더 많이 들어왔습니다. 요청의 대부분은 코드에 두 가지 도구(ESLint와 JSCS) 모두를 사용하고 싶지 않으며, ESLint가 JSCS가 하는 모든 것을 할 수 있다면 JSCS를 버리고 ESLint만 사용할 수 있다는 내용이었죠. 그래서 ESLint에 팀이 생겼으니 이 사용 사례를 지원하기 위해 기능 동등성을 확보하는 데 집중했습니다. 결국 JSCS 사용량이 감소할 정도로 좋은 성과를 거두었고 JSCS를 ESLint에 합칠 수 있었습니다.

당시에는 몰랐던 사실은 JSHint가 올바른 아이디어를 가지고 있었다는 것이고, ESLint가 자바스크립트를 위한 주요 린터(및 소스 코드 포매터)가 되었지만, 그것은 많은 작업을 수행해야 한다는 것을 약속한 것이기도 했습니다.

자바스크립트 급격한 발전과 유지보수의 부담

최근 몇 년 동안 특히 ECMAScript 6와 React의 성장에 영향을 받아 사람들이 자바스크립트를 작성하는 방식이 급격하게 변하고 있습니다. Airbnb와 Standard와 같이 인기를 얻고 있는 스타일 가이드는 자바스크립트 개발자들에게 코드를 작성하는 방식에 대해 더 구체적으로 생각하도록 권장했습니다. 결과적으로 ESLint에 포맷팅 규칙에 대한 예외 및 옵션에 대한 요청이 쏟아졌습니다. 지난 10년 동안 우리는 여러 기이한 스타일과 함께 그것들을 ESLint 핵심 규칙으로 강제하길 원하는 요청을 보았습니다. 그리고 새로운 구문이 도입될 때마다 기존 규칙을 업데이트하고 새로운 규칙을 구현하라는 요청이 쇄도했습니다.

핵심 규칙이 300개에 다다르자, 스타일 규칙을 고정함으로써 유지보수의 부담을 줄이고자 했습니다. 그래서 더 이상 모두의 개인적인 선호사항을 지원하기 위해 세세한 경우를 확인할 필요가 없었습니다. 이는 어느 정도 도움이 되었지만 충분하지는 않았습니다.

• 규칙 간 충돌: 사람들은 핵심 규칙이 서로 호환되어야 한다고 기대합니다. 즉, 두 규칙이 동일한 문제를 강조해서는 안 되며 어떤 두 핵심 규칙도 상충되는 조언을 제공해서는 안 된다는 것을 의미합니다. 핵심 규칙이 30개 미만일 때는 쉬웠지만, 300개가 넘으면서 불가능하진 않더라도 이러한 목표를 달성하기가 어려워졌습니다.
• 비현실적인 기대: 핵심 포맷팅 규칙이 커지면서 사용자들은 플러그인 없이 모든 스타일 가이드를 구현할 수 있을 것으로 기대했습니다. 이로 인해 팀에 더 많은 압력이 가해져 계속해서 옵션을 추가해야 했으며, 이로 인해 라이브러리 코어의 크기도 증가했습니다.
• 노력과 가치의 불일치: 다양한 스타일 가이드를 지원하기 위해 계속해서 새로운 옵션과 예외를 추가하는 유지보수 부담이 ESLint 팀에 가중되는 반면, 그 가치는 소수의 사용자들에게만 전달되었습니다.
• 기회비용: 포맷팅 규칙을 유지보수하는 데 많은 시간을 할애할수록, 많은 사용자에게 도움이 되는 작업에 투자할 시간이 줄어들었습니다.
• 흥미 부족: ESLint는 외부 기여자의 도움을 받고 있지만, 기여자들은 공백에 대한 예외 케이스를 추적하는 데 흥미를 느끼지 않습니다. ESLint 팀 자체는 이러한 작업을 다른 작업보다 훨씬 낮은 우선순위로 두어 종종 오랜 기간 동안 관련된 이슈가 열려 있습니다.
• 일관성 문제: ESLint의 규칙은 원자적으로 설계되어 다른 규칙에 접근할 수 없습니다. 이는 정보가 다른 규칙에 있기 때문에 오류를 올바르게 수정할 수 없는 문제를 야기합니다. 예를 들어, 자동 수정이 새로운 코드 줄을 추가해야 하는 경우 해당 코드가 올바르게 들여 쓰기되어야 하는데, 이를 위해서는 파일의 들여 쓰기 방식을 알아야 합니다. 그러나 들여 쓰기 규칙은 ESLint의 들여 쓰기를 제어하므로, 다른 규칙은 들여 쓰기 없이 수정을 적용하고 이후 들여 쓰기 규칙이 코드를 수정할 것이라고 신뢰해야 했습니다.

이러한 문제들은 ESLint가 오래되면서 계속 증가했고, 마침내 더 이상 따라잡을 수 없는 지점에 이르렀습니다.

더 이상 사용되지 않는 규칙

8.53.0 버전에서 폐기되는 규칙 목록은 다음과 같습니다.

• array-bracket-newline
• array-bracket-spacing
• array-element-newline
• arrow-parens
• arrow-spacing
• block-spacing
• brace-style
• comma-dangle
• comma-spacing
• comma-style
• computed-property-spacing
• dot-location
• eol-last
• func-call-spacing
• function-call-argument-newline
• function-paren-newline
• generator-star-spacing
• implicit-arrow-linebreak
• indent
• jsx-quotes
• key-spacing
• keyword-spacing
• linebreak-style
• lines-between-class-members
• lines-around-comment
• max-len
• max-statements-per-line
• multiline-ternary
• new-parens
• newline-per-chained-call
• no-confusing-arrow
• no-extra-parens
• no-extra-semi
• no-floating-decimal
• no-mixed-operators
• no-mixed-spaces-and-tabs
• no-multi-spaces
• no-multiple-empty-lines
• no-tabs
• no-trailing-spaces
• no-whitespace-before-property
• nonblock-statement-body-position
• object-curly-newline
• object-curly-spacing
• object-property-newline
• one-var-declaration-per-line
• operator-linebreak
• padded-blocks
• padding-line-between-statements
• quote-props
• quotes
• rest-spread-spacing
• semi
• semi-spacing
• semi-style
• space-before-blocks
• space-before-function-paren
• space-in-parens
• space-infix-ops
• space-unary-ops
• spaced-comment
• switch-colon-spacing
• template-curly-spacing
• template-tag-spacing
• wrap-iife
• wrap-regex
• yield-star-spacing

위 모든 규칙은 다음 릴리즈부터 더 이상 사용되지 않지만 최소한 ESLint 10.0.0 버전까지는 제거되지 않을 것입니다. ESLint CLI에 사용 중단에 대한 경고가 표시될 수 있지만 계속 사용할 수는 있습니다.

ESLint를 대체할 수 있는 것

코드 포맷팅을 위해 ESLint 대신 소스 코드 포맷터를 사용하는 것이 좋습니다. 소스 코드 포맷터는 전체 파일을 이해하고 전체적으로 일관된 포맷팅을 적용하도록 만들어졌습니다. 예외에 대한 제어 기능이 ESLint만큼 많지는 않지만, 수십 개의 개별 규칙으로 ESLint를 구성하는 것과 비교하면 단순성과 속도가 향상됩니다. 권장하는 두 가지 포맷터는 다음과 같습니다.

• 프리티어(Prettier) - 다양한 언어의 포맷팅을 지원하는 자바스크립트 기반의 포매터
• dprint - 일부 언어를 지원하는 Rust 기반의 포매터

소스 코드의 포맷팅을 위한 라이브러리를 따로 설치하고 싶지 않다면 자바스크립트의 @stylistic/eslint-plugin-js 플러그인이나 타입스크립트를 위한 @stylistic/eslint-plugin-ts 플러그인을 사용할 수 있으며, ESLint와 typescript-eslint에서 더 이상 사용되지 않는 포맷팅 규칙을 포함하고 있습니다. 이 패키지는 Anthony Fu가 유지 관리하고 있으며, 그는 앞으로도 이러한 규칙을 계속 유지보수하기로 결정했습니다. 이 게시물에 언급된 규칙을 계속 사용하려면 이 패키지로 전환하는 것이 좋습니다.

결론

코드 품질과 포맷팅 목적으로 많은 사람들이 ESLint에 의존하고 있음을 알고 있습니다. 그러므로 이러한 중요한 결정을 경솔하게 내리지 않았습니다. 유감스럽게도 우리가 지금까지 사용해 왔던 방식은 더 이상 효과적으로 확장되지 않을 것이기 때문에 이러한 변화가 필요했습니다. 전용 소스 코드 포맷팅 도구의 보편성과 인기 덕분에 이 결정을 다소 어렵지 않게 내릴 수 있었고, Anthony Fu가 이 규칙을 별도 패키지로 유지보수하겠다고 지원해 준 것도 도움이 되었습니다. 이 게시물에서 언급된 사용 가능한 옵션 중 하나를 통해 사람들이 계속해서 선호하는 방식으로 소스 코드를 포맷팅 할 수 있기를 기대합니다.