VSCODE - eslint & prettier 사용 및 window 에러

프로젝트를 진행하며 프론트 간의 초기세팅시 eslint 와 prettier를 세팅을 진행했고

그 과정에서 나왔던 window가 겪게 되는 error 에 관해서 블로깅을 남겨본다.

ESlint & Prettier ?

ESlint

먼저 간단히 소개를 하자면 ESlint는 해당 소스코드를 확인하여 문법적으로 에러가 있거나 버그를 찾아 보고해주는 역할이다 게다가 틀린 부분을 고쳐주며 가장 인기있는 linter중 하나이다

Prettier

Prettier는 스타일리쉬한 부분을 담당한다 주로 코드의 스타일을 강제 하여 적용한다
여기서 강제라는 말에 주목할 필요가 있는데 원래 코드에 적용되어 있는 스타일을 전부 무시하며 prettier로 설정해준 스타일로 적용이 된다 적용 순서는 settings.json < .editorconfig < .prettierrc 순이다
이로써 자신만의 확고한 코드 스타일이 있다는 사람들은 불편하겠지만 여러 사람들이 그 코드를 읽을때에 가독성은 보장이된다 (물론 prettier 내에서도 개인 설정이 가능하다)

그럼 왜 이 두가지를 같이 써야할까?

한마디로 이야기하자면 ESlint로 기능적인 부분을 도움받고 Prettier를 통해 코드의 스타일을 정리하여 더욱 가독성이 높은 코드를 칠 수 있는 것이다.

설치 부분과 사용 방법은 해당글에 나와있지 않음으로 다른글을 참고하기 바랍니다

CRLF & LF

이 블로깅을 쓰게 되는 이유이다

와디즈 클론코딩 프로젝트 진행중에 있어 같은 프론트 팀원인 Mac 사용 2분과 함께 초기 세팅을 진행중에 있어서 맞닥뜨린 에러며 해결방법이 내 기준에서는 많이 헤멘거 같아 블로깅을 한다

문서의 끝을 개행 처리 함에 있어서는 각 운영체제에 따라 두가지로 나뉘게 된다

유닉스 시스템(맥)에서는 한줄의 끝이 LF(Line Feed)로 처리가 되고
윈도우 시스템에서는 한줄의 끝이 CRLF(Carriage Return Line Feed)로 처리가 된다

그리하여 두개의 운영체제 협업이 일어난다면 치고박으며 싸우게 되고 결론적으로
유닉스 기반 시스템(Linux/Mac OS)은 "나는 LF만 있으면 돼~ 그러니 뭐 알아서들 해~" 라는 입장이며 윈도우 운영체제에서는 "우린 CR도 있어야 한다고 !!" 라는 안타까운 일이 벌어지게 된다

최고의 해결 방법으로는 개발은 "MAC으로 하세요" 라는 답이지만 이미 윈도우로 버티고 있던 나에겐 "MAC은 회사가서 받고 만다" 라는 입장을 포기할 수는 없었다

일단 아래의 그림을 보고가자

이러한 에러가 터미널과 컴파일시 발생을 하게되며 해당 코드를 들어가보면
코드의 끝줄에 빨간색줄로 처리 되어있음을 볼 수가 있다 (끔찍해..😱)

(이녀석을 눌러보면 CRLF와 LF로 수작업으로 바꿀 수 있다 그러면 순간적으로 에러가 사라지는데 여기서 주의할것은 그때만 에러가 사라지는 것일 뿐 결국 다시 일어난다 그러니 잠깐 에러가 사라졌다고 해서 작업을 진행하지말고 해결한 뒤에 진행을 해야한다 나는 이 부분이 해결된줄 알고 진행 하다가 나중에 다시 구글링을 하여 해결하였기 때문에 시간을 더 잡아먹은 것 같다)

구글링을 해보니 개행처리가 일어날때 뜨는 에러를 변환 기능을 원하지 않고 에러메세지를 꺼서
알아서 작업하게 끔하는 core.autocrlf 기능 꺼주기도 있고 eslintrc.json 파일에
라인브레이크 스타일을 바꿔주는 코드 또한 많다

하지만 거짓말 같이 내가 적용을 못하는건가 결국 내 코드에는 적용이 되지 않았고

찾은 방법으로는 아래와 같다

eslint 와 prettier를 같이 쓰기 위해 설정한 eslint-config-prettier에서 라인 엔딩 관련해 에러설정을 자동으로 변경시켜주는 코드이다

또한 이렇게 설정해도 Git branch 이동 간 CRLF로 되돌아오는 경우가 많은데
그런 경우에는 해당 프로젝트 최상위 폴더에 .gitattributes 파일을 생성 한 뒤 아래와 같은
코드를 입력해주면 된다

한줄평 : 개발은 맥으로