초보인 내가 ESLint에 merge 성공?! 上편(with 오픈소스 컨트리뷰톤)

soda-melon·2020년 9월 2일
20
post-thumbnail

(제목귀엽게 봐주시면 감사합니다...❤)

안녕하세요?sodaMelon입니다!!
저는 웹 개발에 입문하면서 코딩컨벤션(코딩 스타일)에 관심을 가지게 된 코린이입니다...

컨트리뷰톤 참여자 모집 당시, 그 관심을 열심히 어필한 덕분일까요?
평소에도 운이 좋은 편이긴 하지만,
이번에도 행운의 여신이 함께하셔서....!
공개SW 포털의 오픈소스 컨트리뷰톤 ESLint팀에 멘티로 참여하게 되었는데요.

얼마 전, 넣었던 pull request가 master에 merge가 되서...
본격적으로 released 되기 시작하니 너무 기뻐서...그만......

그래서 행복한 경험을 자랑공유하고자 오픈소스 컨트리뷰션 후기 글을 남기게 되었습니다.
오픈소스 기여에 도전하고자 하시는 분들께 도움이 되었으면 좋겠어요!! ㅎㅅㅎ


0. ESlint에 기여하게 된 계기

(이미 쓰시는 분들이 많을 것 같지만) ESLint가 어떤 프로젝트인지 간단히 소개를 하겠습니다.

코드를 분석하여 일관적인 코딩 컨벤션을 유지하도록 도와주고, 문법적인 오류/잠재적인 버그를 찾아주는 도구를 Lint라고 합니다.
그 중에 ESlint는 많이 사용되는 "JavaScript를 위한 Lint"입니다.

<참고하면 좋은 ESLint 가이드 컨텐츠(한국어)>



저도 학생때는 이런 도구가 있는지 모르다가 🤔

  • 인턴하면서 코딩 컨벤션coding convention이 있다는걸 알게되서 크게 삽질을 하고....
  • 아 이거 뭐 자동으로 잡아주는 거 없나..
  • 커밋하기전에 검사하면 코드리뷰에서 걸리는 일도 없을거고.. 좋을텐데......

하는 생각을 했고...
관련해서 더 찾아보다가 코딩 컨벤션을 자동화해주는 도구를 쓴다는 기술 블로그를 읽으면서, '오... 좋은데?' 했지만 그때는 도입할 여유가 없어서 그냥 지나갔습니다.(..)

그러다가 나중에 프로젝트를 끝내고 나니
ESLint가 보이기 시작했고, 적용해보니까 확실히 작업 효율이 좋아진 거 같아서🤗
같이 공부하는 팀원들한테 영업하려고, 사전 공부겸 컨트리뷰톤에 신청했습니다.


1. 이슈 선정

일반적인 이슈 선정방식에는 팀 프로젝트처럼 github repository 의 issue 에서 적당한 이슈를 고르거나, 새 이슈를 찾아 작성하는 방법이 있는데요.

당시에는 오픈소스 라이프 사이클도 잘 모르겠고..
ESLint는 유명한만큼 완성도가 높아서..
처음부터 기여하는건 좀 어렵다는 생각이 들었습니다.

그래서 한참 issue 목록들을 방황하다가....

3달 전쯤, 기존 기여자가 issue 제안후 해결하다가, 바빠서 더이상 투자할 시간이 없다고 남긴 issue인 [eslint/eslint/#13094] (https://github.com/eslint/eslint/issues/13094)를 발견했습니다.

연관되어 있는 Pull request을 확인해보니, 소스코드들이 남아있었고...
저는 그저..

라는 생각에
기존 issue에 "중단된 거 같이 보이는데, 제가 이어서 해도 될까요?" 하고 코멘트를 남겼습니다.
그리고 ESLint maintainTeam중에 한분이 sure라고 답신을 주셔서!

해당 이슈를 이어하게 되었습니다. 😎🎉🎉

(Tip: 처음 할때는 docs의 오타를 고치는 것도 추천드립니다. 간단한 일이지만, 중요한 일이고 PR 빠르게 진행되기 때문에, 빠르게 FLOW를 알수 있어서 좋아요!!)


2. ~PR을 보내기 전까지

(부제: 이슈 해결하기)

2.1 연관된 rule 파악하기

제가 맡은 issue#13094는 ESLint의 규칙 중 하나인 [id-length] rule과 연관되어 있는데요.
해당 규칙은 identifier(식별자) 최소 길이(글자수) 또는 최대 길이에 대해서 제한하는 규칙입니다.

e, x, _t  : 너무 짧아서 의미가 불분명함
hashGeneratorResultOutputContainerObject : 너무 길어서 가독성이 떨어짐

같은 부적절한 식별자들을 사용자가 미리 정해둔 min/max property값을 기준으로 length를 검사하기도 하고

{
  id-length: {
    min: 3,
    max: 10,
    "exceptions": ["x"] 
  }
}

처럼 예외사항에 x 를 추가해두면, x라는 이름을 가진 식별자는 rule로 검사하지 않고 넘어가게 예외 처리를 할수 있는 규칙입니다.

2.2 이슈 해결하기

여기서 제가 맡은 이슈issue#13094는 exceptionPatterns라는 property를 추가해서 패턴 예외 property를 만드는 일입니다.

( 만약 { "exceptionPatterns": ["^BEFORE_"] }라면, BEFORE_로 시작하는 모든 식별자에 대해 검사를 pass하는 완전 편리한 기능입니다.👍)

먼저 예전 PR에서 필요한 부분을 가져온 후, 남겨진 리뷰 코멘트들을 확인하면서 테스트 케이스를 추가하고 불필요한 부분을 수정했습니다.

문제는 그다음 리팩토링 관련 코멘트였습니다.

@mdjermanovic : Perhaps we should extract this to a function and call that function in the if below, to avoid creating new RegExp instances (and testing) for each identifier in the source code, including those that have a valid length.

(번역: 아마 우리는 이것을 function으로 추출해서, if문 아래에서 저 function을 호출해야합니다.
소스코드의 각각의 식별자(길이가 올바른 식별자들 포함)마다 새로운 RegExp instance가 생성되는 것을 막기위해서요!)

여기서 이것this은 exceptionPatterns을 검사항목들과 매칭시키는 메인 로직부분이였고....

저는 당시... 부분부분은 이해가지만...

전체적으로 eslint는 어떻게 돌아가는거지..? 하고 파악을 못하고있었습니다.

마치 Java Spring Framework를 처음 배웠던 그 때처럼요.😱

이 때, 하루이틀정도 삽질을 하다가, 새벽에 갑자기... 두번째 오프라인 스터디 시간에 멘토님이 가르쳐주신 chrome으로 node 디버깅 하는 방법이 생각났습니다.

✔ chrome으로 디버깅하기

센스쟁이 개발자분들은 이미 잘 활용하고 계시겠지만, Node.js inspector를 이용하면, console.log(something)보다 훨씬 효율적으로 디버깅을 할 수 있습니다ㅎㅎ..

npx mocha "테스트 파일.js의 상대경로" --inpect-brk
  1. 디버깅을 하고 싶은 코드 라인 상단에 debugger; 를 추가한다.
  2. 위와같이 --inpect-brk 옵션을 붙여서 해당 테스트코드를 실행한다.
  3. 크롬브라우저 URL에 chrome://inspect로 접속하여 Target에 inspect를 클릭한다.
  4. chrome devtools를 이용해 step을 사용한 디버깅을 할 수 있다.
    (출처: https://dididy.github.io/til/retrospect/2020-08-contributhon)

이 방법대로 터미널에 입력하는 방법으로 디버거를 실행하게 되면

이런 dev tool의 도움을 받아, test case를 받은 소스코드가 어떻게 case들을 받아 판단하는지 확인할 수 있습니다.
(꼼꼼한 테스트 코드 덕분에 ,마음의 평화는 덤으로 옵니다!)

눈으로 context가 어떤 내용을 받아서 뿌려주는지 보고나니, review대로 추출하는 건 어렵지 않아서 이후에 함수를 분리해주고, JSDoc 스타일로 주석을 붙여주니 해당 코멘트를 해결 할 수있었습니다.

2.3 연관된 guide docs 작성하기

React 좋아하시는 분이라면 그저 사랑인 react docs..♥
node.js하시면 자주 보실 설명서, sequelize docs 처럼 

ESLint에도 당연히 사용자 전용 설명서인 documentation이 있습니다.
새로 기능을 추가했으니, 설명서에도 새로운 기능에 대한 설명과 예시를 추가해야합니다.

처음에는 약간 영어의 압박이 느껴졌는데...🙃
다른 사람들이 쓴 rule들을 참고하면서 비슷하게 작성하다보니, 생각보다 금방 써져서.. 🥰
실제로는 이 작업에 제일 적은 시간을 들였던 것 같습니다.

그리고 문서작업을 끝내고 나니 진짜 끝났다는 느낌이 들어.. 기분이 좋았습니다...🎉

🔥 이젠 정말 PR만 남았습니다...

(생각보다 글이 길어져 2편에서 계속됩니다... to be continue....)
(읽어주셔서 감사합니다!)

profile
삽질 driven development... 좋아하세요?

2개의 댓글

comment-user-thumbnail
2020년 9월 14일

상편 하편 모두 읽어봤어요~~ 보통은 eslint같은건 가져다쓰기만 하고 이미 잘 만든 툴이라 컨트리뷰트하기 어려울거라고 생각했는데.... 생각보다 쉽게 기여할 수 있는 이슈도 있군요 ㅋㅋㅋㅋㅋ 보너스 나오면 기분겸 페이팔로 기부나할까했는데~~~ 기부하기전에 저도 이슈나 한번 찾아볼까봐요 ㅎㅎ 기여 과정 잘읽었습니다 ^^

1개의 답글