뭐가 문제인데?
여러 사람들과 프로젝트를 진행하다 보면 각각의 사람들의 코드 품질이 다르다. 코드 품질이 다른 이유는 몇 가지가 있다. 에디터의 세팅이 다르거나 각각의 개발자들의 스타일 차이, 개발 수준의 차이도 있을 수도 있다. 프로젝트를 진행하다 보면, 어떤 개발자는 자체적인 코드 스타일로 작성하기도, 어떤 개발자는 잠재적인 오류코드를 생산하면서 작업하기도 한다. 이러한 코드 방식은 개발 중에는 문제가 생기지 않을 수 있지만, 빌드 하는순간 모든 것이 망가지기도 한다. 이러한 문제를 개발 중에 어느 정도 보장할 수 있으면 좋지 않을까?
ESLint
ESLint는 한마디로 정리 할 수 있다.
코드를 분석하여 코드 품질을 높이고, 올바른 형식을 유지하는데 도와주는 도구
중요한 것은 도와주는 도구이다. 절대로 변경해 주는 도구가 아니다. ESLint를 지키지 않는 것은 결과적으로 문제가 생기지 않을 수 있지만, 모두의 규칙을 해치거나 잠재적 문제를 발생시키고 있을지도 모른다.
보완점이 발생하면 위의 이미지와 같이 사용한다. 해당 이슈들이 발생하면, 수정하는 것을 추천한다.
// .eslintrc.cjs
/* eslint-env node */
require('@rushstack/eslint-patch/modern-module-resolution');
module.exports = {
root: true,
extends: ['plugin:vue/vue3-essential', 'eslint:recommended', '@vue/eslint-config-typescript', 'plugin:storybook/recommended'],
ignorePatterns: ['build', 'dist', 'public'],
parserOptions: {
ecmaVersion: 'latest'
},
rules: {
'no-console': ['error', {allow: ['warn', 'error', 'info']}],
'quotes': ['error', 'single', {'allowTemplateLiterals': true}],
'semi': ['error', 'always'],
'no-extra-semi': 'error',
'no-debugger': 'error',
'semi-spacing': 'error',
'vue/multi-word-component-names': ['off'],
'vue/no-mutating-props': 'off',
'no-extra-boolean-cast': 'off',
'no-case-declarations': 'off',
},
};
Prettier
Prettier는 한마디로 정리 할 수 있다.
정해진 코드 스타일을 따르도록 코드를 변경해 주는 도구
중요한 건 변경해 주는 도구이다. Prettier는 Prettier가 원하는 방식대로 코드를 수정해 준다. Prettier는 코드를 분석해 문제가 생길만한 부분을 잡아 주거나 알려주는 도구는 아니다. 단순 코드 스타일을 강요? 변경해 주는 도구이다.
// .prettierrc.json
{
"printWidth": 120,
"tabWidth": 2,
"semi": true,
"singleQuote": true,
"quoteProps": "as-needed",
"trailingComma": "none",
"bracketSpacing": false,
"bracketSameLine": true,
"arrowParens": "always"
}Prettier는 내 스타일대로 코드 스타일을 절대 설정할 수 없다. 옵션을 작성해서 내 마음대로 하지도 못하게 막아놓았다. Prettier에서 이렇게 강제적으로 코드 스타일을 변경하는 것은 이유가 있다.
스티브 잡스가 매일 똑같은 옷을 입던 모습을 떠올리게 합니다. 그는 수많은 결정을 내려야 했고, 옷 고르기 같은 사소한 결정을 내리고 싶지 않았거든요. Prettier도 그런 것 같아요.
Prettier는 더 이상 코딩 스타일에 대하여 시간을 낭비하지 않겠다.로 시작한다는 것입니다. 코딩 스타일 때문에 빌드가 밀리고, 프로젝트마다 코딩 스타일이 다름에 대해서 매번 다르게 설명하고 교정하고 의논하는 시간이 소모적이라고 판단했습니다. 그리고 개발자가 공백을 추가하지 않는 것을 실수하거나 잘못된 스타일로 작성되었을 때 자동으로 변경해 준다.
Prettier는 이와 같은 사상 때문에 제공하는 옵션도 많지 않다. Prettier의 옵션이 많아질수록 위의 이야기한 사상에서 더 멀어진다고 생각하는 것 같다.
스타일을 둘러싼 논쟁은 어떤 Prettier 옵션을 사용할 것인가를 둘러싼 논쟁으로 변할 뿐입니다.
그래서 Prettier는 다양한 옵션을 제공하지 않는다. 단지 "희생"할 가치가 있다고 이야기한다.
문제
function ERROR1 () {
const data
= 1
}변환
function ERROR1() {
const data = 1;
}그래서 나는?
ESLint
나의 프로젝트에서는 typescript를 중점적으로 사용하고 있다. 예전에는 tslint를 사용하고 있었는데 ESLint로 병합되면서 새로 시작하는 프로젝트부터는 ESLint를 적극적으로 사용하고 있다.
Prettier
나는 예전부터 WebStorm의 Code Style을 강제적으로 적용하도록 인수인계하고, 계속 필요에 따라서 유지보수 해왔었다. 이에 드는 비용은 상당히 많이 들었던 것 같다. 이러한 방식은 사람마다 코드 리뷰에 많은 시간을 쓰게 되고 에디터도 한정적으로 사용할 수밖에 없었다. 그런 것을 바꿔줄 수 있는 게 Prettier라고 생각한다. 나는 더 이상 코드 스타일에 시간을 사용하고 싶지 않다. Prettier는 에디터에 종속적이지도 설명을 하지 않아도 된다. 그냥 실행될 뿐. 그럼에도 Prettier plugin 혹은 extension을 설정하는 방법과 githook을 설정하는 방법만 설명하면 될 뿐이다.
