eslint

단순했던 첫 배포 파이프라인Kampus 프로젝트는 초기 Git Flow 를 따르자고 정했다. feature 브랜치에서 develop 으로 PR 을 올렸을 때 → Squash and merge → merge 후 remote branch 삭제기능 단위로 개발한 브랜치이기 때문에, 개발서버에도 기능 단위 커밋을 관리할 수 있다. 브랜치를 삭제하므로 merge commit 을 남길 필요가 없다. develop 브랜치에서 main 브랜치로 배포 돌릴 때 → Rebase and merge 모든 기능을 배포할때 병합한다. 특정 기능에서 문제가 발생했을 경우 롤백이 필요하다. merge commit 을 남길 필요가 없다. Git Flow : 초기에는 지키려고 노력했지만, 데모데이가 다가오며 많아지는 merge 와 배포..

eslint 8버전 공식문서를 확인하면, 아래 종류의 파일을 린트 포맷 설정하는 파일로 작성할 수 있다고 한다.그러나 eslint v.8.23.0 부터 flat config 가 표준이 되었다고 한다. 즉 eslintrc.~ 형식을 지양 (❌) 하는 것1. eslint.config.js 가 무엇인지 알고, eslintrc.cjs 의 차이점이 무엇인지 정리해보자.2. Kampus 프로젝트에는 어떤 방식을 사용할까?Kampus 프로젝트는 런닝커브와 유연성으로 인해 자바스크립트 언어로 구성되어 있다. (타입스크립트로 개선하자는 이야기가 있다!)unused imports, vars 를 감지하여 warn 을 표시하는 규칙이 필요했다. 린트가 없는 상황에서 -> 미사용 변수 및 함수, import 문이 곳곳에서 표시..