[MGS 3기 - 27일차] React 추가 학습

박철연·2022년 5월 18일
0

MGS STFE 3기

목록 보기
24/35
post-thumbnail

오늘까지 예정되어 있던 React 강의를 어제부로 완료했습니다. 오늘은 리액트로 프로젝트를 구성할 때, 필요한 사전 설정들을 개인적으로 공부해 정리해보았습니다.

React & ES Lint

Linter는 무엇인가

위키에서 린트를 한번 검색해보았습니다. 다음과 같은 설명이 나오는군요.

린트(lint) 또는 린터(linter)는 소스 코드를 분석하여 프로그램 오류, 버그, 스타일 오류, 의심스러운 구조체에 표시(flag)를 달아놓기 위한 도구들을 가리킨다.

린트는 쉽게 말해서, 코드의 문법 오류나 패턴에서 벗어난 코드를 지적해줍니다. 결과적으로 일관된 스타일로 코드를 작성할 수 있게 해주는 도구입니다.

Lint라는 단어가 영어로 '보푸라기'를 뜻합니다. 그래서 문법이나 컨벤션에 어긋난 코드를 찾아내서 거기에 표시를 시켜준다고 생각하시면 되겠습니다.

린트는 생각보다 역사가 오래된 도구입니다. 무려 1978년에 발명이 되었기 때문이죠. 벨 연구소 소속이었던 미국의 기술자가 유닉스 운영 체제를 다루다가, 자신의 코드를 디버깅하는 과정에서 만들게 되었습니다.

ESLint

ESLint는 EcmaScript + Lint로, 자바스크립트 문서 상에서 사용하는 린터를 지칭합니다. 자바스크립트 말고 JSX에서도 동작하기 때문에, React로 개발을 진행하는 상황에서도 매우 유용하게 사용할 수 있습니다.

사실 자바스크립트에서 사용할 수 있는 린터에는 JSHint, JSLint, JSCS 등 다양한 종류가 있지만, 현 시점에서는 ESLint가 가장 보편적으로 사용됩니다.

그 이유는 플러그인 때문입니다. ESLint는 플러그인을 지원하는데, 여기서 말하는 플러그인이란 도구의 확장성을 위해 추가된 애드온 같은 개념입니다.

다양하고 유용한 플러그인들의 지원에 힘입어 ESLint는 자바스크립트를 다루는 개발자들에게 필수불가결한 도구로 자리매김했습니다. 이제 본격적으로 ESLint를 사용하는 방법에 대해 알아보겠습니다.

ESLint 설치

내용 정리를 하기 쉽도록 ESLint를 셋팅하기 위한 폴더를 하나 만들어 주었습니다. 그리고 나서 npm init으로 패키지 관리를 시작했습니다.

여기에 먼저 ESLint를 설치해야할 것입니다. 터미널에서 다음 명령어를 입력하세요.

npm i eslint -D

당연히 개발 환경에서만 작동하는 도구이므로 -D를 추가해 개발 의존성을 가지고 설치해주시는 것이 좋겠습니다.

패키지에 ESLint가 추가된 것을 확인하셨다면 다음으로 넘어갑시다.

npx eslint --init

위 명령어를 입력하면 설치된 ESLint가 초기화됩니다.

명령어를 입력하면 다음과 같은 선택지가 나오게 됩니다. 제일 하단 부분에 파란색으로 하이라이트된 문장을 참고하세요.

이는 ESLint로 무엇을 할 것인지 설정하는 부분으로, 여기서 택일을 하면 ESLint와 관련된 config 파일이 생기게 됩니다.

문법만 체크할래, 체크하고 오류 수정까지 할래? 아니면 전체적인 코드 스타일까지 통일시킬래? 뭐 그런 선택지입니다.

이것 말고도 선택지를 고르는 항목이 여러 개 이어질텐데, 본인 개발 환경을 반영해서 열심히 골라주시면 되겠습니다. 꼭 이거 골라야 제대로 작동한다! 이런 건 없습니다.

다 마치면 ESLint 설정 파일이 생긴 것을 확인할 수 있습니다. 왼쪽에 eslintrc.js를 확인할 수 있을 것입니다.

여기까지 하셨으면 ESLint를 성공적으로 설치한 것입니다. 이제 저 파일을 가지고 ESLint를 자신의 상황에 맞게 셋팅해 보겠습니다.

ESLint 셋팅

방금 생성된 eslintrc.js은 ESLint가 어떤 부분을 체크하고 수정할 것인지 세세하게 설정할 수 있는 파일입니다.

정말 디테일한 것까지 설정할 수 있는데, 저는 이번이 처음 써보는 것이니 간단한 설정부터 추가해보겠습니다.

보통 자바스크립트를 쓰면 세미콜론(;)을 식 뒤에 붙이죠? 저는 처음에 안쓰는 버릇을 하다보니 요즘도 가끔씩 빼먹습니다. 이 세미콜론을 안 붙이면 회초리를 들도록 ESLint를 설정해 보겠습니다.

다른 건 건드릴 필요 없고, 아래 쪽에 보면 rules 부분이 비어 있는 것을 알 수 있습니다. 이 부분에 세미콜론 설정을 다음과 같이 입력해 주었습니다.

이제 실제로 어떻게 적용되는지 한번 알아볼 필요가 있겠습니다.

빠르게 index.js 파일 하나 만들어서 아주 간단한 콘솔 로그 하나 찍어 보았습니다.

여기서 터미널에 다음 명령어를 입력해 보면 자세한 린팅 사항을 확인할 수 있습니다.

npx eslint 파일명.js

세미콜론을 빠뜨렸다고 친절하게 알려주고 있는 것을 확인할 수 있습니다.

ESLint 플러그인

방금 보셨다시피 명령어로 ESLint의 동작을 잘 확인 할 수 있습니다. 그런데 매번 코드를 치고 명령어를 입력해서 수동으로 확인하는 건 좀 귀찮지 않을까요?

이를 위해 ESLint 플러그인 하나를 설치해보려고 합니다. VSCode의 확장(extension) 부분을 들어가서, ESLint를 검색해 보세요.

설치하고 나서 VSCode를 다시 로드해보겠습니다.

이제 따로 명령어를 입력하지 않아도 알아서 문서에 오류를 띄우고 있군요. 이렇게 ESLint 플러그인을 사용하면 린팅을 더욱 효과적으로 할 수 있습니다.

제가 서두에 말씀드린 것처럼, ESLint는 이런 플러그인들에 힘입어 아주 유용한 린터로 자리잡았습니다.

ESLint와 CRA

정작 React 시리즈인데, React는 안나오고 자바스크립트로만 ESLint를 설명했습니다. 이제 기본적인 지식을 바탕으로 ESLint와 React 프로젝트를 연결해 볼 차례입니다.

먼저 CRA로 따끈따끈한 프로젝트 하나를 준비해주세요. 그런 다음 package.json을 살펴 봅시다.

관심이 없을 땐 몰랐는데, 이미 CRA는 eslint 설정을 포함하고 있었군요.

우리가 직접 ESLint를 깔았을 때, eslintrc.js 파일을 설정했었는데, CRA로 프로젝트를 생성하면 그 부분을 package.json에 포함시켜 주는 것입니다.

(실제로 node_modules 폴더 안에서도 잘 찾아보면 ESLint와 관련된 파일들을 찾을 수 있습니다.)

그래서 CRA 상에서 ESLint는 이미 기본적인 설정이 끝나 있는 상태이고, 여기에 개발자가 rules를 추가하여 더 세밀한 설정을 할 수 있는 것입니다. 이런 식으로요.

바닐라 자바스크립트로 설정했을 때와 동일한 rules를 추가해주었습니다. 이 외에도 본인이 린터에 추가하고 싶은 설정들을 구글링을 통해 추가하면, React 프로젝트를 진행하는 중에도 ESLint의 기능을 알차게 활용 할 수 있을 것입니다.

React & Prettier

코드 포맷터(Code Formatter)

코드 포멧터(Code Formatter)란 개발자가 작성한 코드를 미리 정해진 코딩 스타일을 따르도록 변환해주는 도구를 말합니다.

언뜻 생각하면 저번 글에서 다루었던 린터와 비슷한 기능을 하는 것 같기도 합니다.

린터는 주로 코드 내의 에러를 검출하고 코드 문법을 강제하는 등 코드 품질을 향상시키는 것이 주요한 기능입니다.
(ESLint 같은 경우에는 기본적인 포맷팅 기능도 같이 탑재되어 있습니다.)

포맷터는 indent 길이, 따옴표 종류, 한 줄 안에서 코드의 최대 길이 등 코드의 모양새를 미리 정해진 규칙에 따라 손질해주는 것입니다. 따라서 실제 코드의 오류를 잡아주거나 하지는 못합니다.

원래 개발을 할 때에는, 동료 개발자와 협업하여 코드를 작성하는 경우가 부지기수입니다.

그런데 저는 작은 따옴표를 쓰고, 동료는 큰 따옴표를 씁니다. 또 동료는 들여쓰기 간격이 4인데, 저는 2에요.

그러면 같은 프로젝트를 진행하는데도 서로 다른 모양의 코드가 산재하게 되니 나중에 코드를 읽는 입장에서 어수선하고, 타인의 코드를 고치는 작업도 불편해질 것입니다.

이를 위해 탄생한 것이 바로 코드 포맷터이고, 이 중 가장 대표적인 것이 오늘 우리가 살펴볼 Prettier입니다.

Prettier를 쓰는 이유

현재 가장 널리 쓰이는 코드 포맷터는 Prettier입니다. 자바스크립트 라이브러리이며, Facebook, Paypal 등 많은 개발 친화 기업들이 Prettier를 표준으로 삼고 있습니다.

Prettier가 많은 개발자들에게 채택이 된 이유는 간단합니다. 바로 설정이 거의 필요 없다는 점입니다.

Prettier가 가지고 있는 기본 포맷팅 설정은 대부분 보편적인 코드 포맷팅 룰을 준수하고 있으며, 실제로 개발자들이 일부러 설정을 추가할 필요가 거의 없다는 것이죠.

즉, Prettier만 쓰면 보편적인 코드 컨벤션을 거의 다 준수하게 된다는 것입니다. 그래서 실제로 Prettier의 웹사이트를 방문해보면 'Opinionated Code Formatter'를 표방하고 있기도 합니다.

또한 Prettier는 코드를 수정만 해주는 것이 아니라 구문을 분석한 다음 코드를 다시 재작성하는 형태인데, 이 때문에 코드의 실행을 보장하면서도 좋은 성능의 포맷터로 자리매김했습니다.

Prettier 사용법

설치는 npm으로 간단하게 끝낼 수 있습니다.

$ npm i prettier -D

개발 의존성 모드를 적용하여 설치하시면 됩니다.

그런 다음, 저는 포맷팅 결과를 관찰하기 위해 index.js 파일을 만들고, 다음과 같은 간단한 문장을 콘솔에 출력해보았습니다.

이제 Prettier 동작을 실행시키기 위해 다음 명령어를 터미널에 입력해보겠습니다.

$ npx prettier index.js

그랬더니 Prettier에 내장된 규칙들을 적용되어서, 작은따옴표가 큰 따옴표가 되었고, 뒤에 세미콜론도 추가되었습니다.

만약 Prettier를 적용한 코드를 실제 문서에 바로 적용하고 싶다면 다음 명령어를 입력하시면 됩니다.

$ npx prettier index.js --write

VSCode 익스텐션을 통해 포맷팅을 자동화할 수도 있습니다.

위에 보이시는 Prettier 익스텐션을 설치하시면 아래처럼 기본 포맷터로 Prettier를 설정할 수도 있답니다.

(VSCode 기본 설정에 form만 치셔도 기본 포맷터 설정 항목에 접근할 수 있습니다.)

저 같은 경우에는 아래쪽처럼 저장할 때마다 자동으로 포맷팅을 해주는 기능도 활성화시켰습니다.

이후에 코드를 작성하면 저장을 하기만 해도 Prettier 포맷팅이 자동으로 적용된 채 저장될 것입니다.

간단하게 Prettier 사용법을 알아 보았는데, 포맷팅 설정을 내 입맛대로 조금 바꾸고 싶으신 분들은 다음 링크를 참고해 보세요. Prettier 공식 웹사이트에 기재된 옵션 docs 입니다.

https://prettier.io/docs/en/options.html

ESLint & Prettier

아까 말씀드린 것처럼, ESLint 내에도 기본적인 포맷팅 기능이 포함되어 있습니다.

다만, Prettier처럼 디테일하지 않기 때문에, ESLint와 Prettier를 함께 쓰는 경우가 상당히 많습니다.

따라서 두 도구를 함께 사용하되, 문법 오류나 코드 에러를 정적으로 분석할 때 ESLint를 적극 활용하고, 포맷팅을 Prettier로 하는 게 좋아보이네요.

한 가지 주의점이 있다면, ESLint와 Prettier 모두 포맷팅 기능이 있다 보니 때때로 충돌이 일어날 수 있다는 점입니다.

이런 잠재적 문제는 다음 패키지를 설치해서 해결해 봅시다.

$ npm i eslint-config-prettier -D

eslint-config-prettier는 ESLint와 Prettier 사이에 충돌할 가능성이 있는 포맷팅 기능을 비활성화 시켜줍니다.

패키지를 설치하고 나면, ESLint를 사용하기 위해 만들었던 .eslintrc.json 파일에 다음 코드를 추가해주면 됩니다.

{ 
  "plugins": [ "prettier" ], 
    "rules": { "prettier/prettier": "error" } 
}

이후에는 ESLint가 린팅을 하면서 자동으로 Prettier의 포맷팅도 수행합니다.

Husky

Husky 간단 소개

Husky는 개발 환경에서 Git Hooks를 사용하기 쉽게 만들어 주는 도구입니다.

Git Hooks은 git을 쓰다가 특정 이벤트(commit이나 push 같은)가 일어나는 순간에 특정 스크립트가 실행되도록 도와주는 것입니다.

Git으로 버전 관리를 할 때 생성되는 .git/hooks 폴더에 스크립트를 직접 넣어도 이런 Git Hooks 관리를 할 수 있습니다.

다만, .git/hooks 폴더 같은 경우에는 형상 관리를 받지 않기 때문에 따로 케어를 해줘야 하고, npm 명령어를 스크립트에 쓰는 경우에는 직접 파일을 작성하는 것이 번거롭습니다.

그래서 husky를 사용하여 좀 더 편리하게 Git hooks를 관리해준다고 보시면 될 것 같습니다.

husky 설치하기

일단 husky 설치를 진행하기 위해 husky라는 폴더를 하나 만들어 주고, npm init -y로 패키지 관리를 시작해주었습니다.

그리고 husky를 설치하기 전에 반드시 git init을 해줘야 합니다. git이 작동하지 않는 상태에서는 husky를 설치해도 hooks를 조작할 수 없습니다.

git init을 입력했고, master라는 브랜치가 잘 나오는 것도 확인했습니다. 이제 다른 패키지들 처럼 husky를 npm으로 설치해 주시면 되겠습니다.

$ npm i husky -D

개발 의존성으로 설치하시면 됩니다. 설치된 것을 확인하셨다면 husky를 설치한 폴더를 코드 에디터로 열어봅시다.

폴더를 연 뒤, husky에서 Git hooks에 대한 조작을 활성화하기 위해 명령어를 하나 더 넣어주어야 합니다.

$ npx husky install

해당 명령어를 입력하면 Git hooks가 설치되고, 실제 폴더로 확인할 수 있습니다.

왼쪽에 husky 폴더가 생성된 것 보이시죠? 여기까지 문제없이 오셨다면 다음으로 넘어가시면 되겠습니다.

husky 사용법

처음 npm init을 하면 package.json 파일의 스크립트에는 test라는 키워드 하나만 있을 텐데, 저는 커밋을 하기 전에 이 test 스크립트가 실행되도록 해보고 싶습니다.

$ npx husky add .husky/pre-commit "npm test"

Git hooks를 추가할 때에는, add .husky/~~ 의 형식으로 작성하시면 됩니다. 저는 test 스크립트를 실행하기로 했으니 "npm test"를 넣어주었습니다.

명령어를 입력하면 다음과 같이 created되었다는 메시지가 뜨고, husky 폴더 안에 pre-commit이라는 폴더가 생긴 것도 확인할 수 있습니다.

이제 해당 폴더는 커밋을 할 때 마다 npm test 스크립트를 수행하게 됩니다.

profile
Frontend Developer

0개의 댓글