[TIL-26] 실전 프로젝트 - 프로젝트 셋팅(SCSS, ESLint, Prettier설정)

Today목표 : 05/22일~05/23일 실전 프로젝트 : 프로젝트 셋팅(SCSS, ESLint, Prettier설정)

실전 프로젝트가 시작됐다. 6주간의 기간 동안 프론트2 백엔드3 디자이너1 으로 팀을 이뤄 하나의 프로젝트를 완성해야 한다.

같이 협업해야 하는 만큼 프로젝트를 잘 설계하고 사용할 stack들을 결정하는 것이 중요했다. 

오늘은 프로젝트 셋팅에서 SCSS, ESLint, Prettier를 설정하였고, 궁금했던 부분들이나 이런 stack들을 사용한 이유를 정리해 보려고 한다.

---

알게된점,

 

1. SCSS사용시 yarn add node-sass 하는 이유 ✅

yarn add node-sass
yarn add sass

=> node환경에서 sass 파일을 감시하여 컴파일 할 수 있도록 하기 위해서다.

> node-sass [옵션] <인풋파일> <아웃풋파일>
> node-sass -w scss/style.scss css/style.css --output-style compressed

 

2. SCSS에서 모듈화를 선택한 이유✅

import styles from "./Box.module.scss";

모듈화가 필요한 이유는 ?

클래스의 이름을 고유하게 바꿔주기 때문이다.
프로젝트가 커지면 본의 아니게 같은 이름을 사용하는 경우가 생기게 된다. 각각의 이름을 고유하게 만들어서 본의아니게 겹치지 않도록 만들어주는 역할을 하는 것이 module이기 때문에 혹여나 겹치는 네이밍이 없게 하기 위해 모듈화를 시켜 준다.

1) 일반적으로 import하여 사용할 때

import './input.scss';
<input
      className="input"

2) 모듈화 했을 때

import styles from './input.scss';

<input
      className={styles.input}

맨 처음에 클래스 이름으로 지어줬던 값이 “키”가 되고 고유한 이름이 “값”으로 이루어져 있는 객체의 모습을 확인할 수 있다.

=> 파일명에 .module붙여서 모듈화 하면 => 일반적으로 import 하여 className에서 쓸 수 없다.

 

 

 

3. ESLint 설정에서 모든 팀원들이 프리티어 자동 저장 적용되도록 .vscode 설정하기✅

모든 팀원들이 format on save => 프리티어 자동 저장이 되도록 프로젝트에서 .vscode 설정파일 설정하기

.vscode 폴더 내의 setting.json 파일에서 다음과 같이 설정

{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
}
}

파일을 저장할 때 자동으로 포맷팅 및 ESLint 에러를 자동으로 수정하도록 설정한다. 

.vscode/settings.json 파일을 프로젝트에 추가하고 위 코드를 저장하면, VS Code는 프로젝트의 코드 포맷팅 및 ESLint 에러 자동 수정을 강제로 적용된다. 이 설정 파일은 프로젝트 저장소에 포함되므로 다른 팀원들도 동일한 설정을 갖게된다. => 다른 팀원들이 VS Code를 사용하고 있는지 확인하고, 팀원들에게 해당 설정을 사용하도록 안내하는 것이 좋다. 또한, 이 설정은 팀원들이 VS Code에서 작업할 때만 적용되는 것이므로 다른 에디터를 사용하는 경우 별도의 설정이 필요할 수 있다.

 

 

목표 달성 여부,

1. 프로젝트 셋팅, 폴더 구조 설계 ✅

2. SCSS 설치 및 SCSS폴더 구조 설계 ✅

3. ESLint airBnB와 Prettier 연동 및 설정 ✅

 

 

느낀 점,

ESLint airBnB 와 Prettier를 사용하여 프로젝트를 진행할 때 다른 팀원과 컨벤션을 강제하여 가독성이나 유지보수에 있어 통일되는 스타일로 코드를 작성 하고자 했다. 하지만 설정이 생각보다 정말 너무 어렵고 복잡했다...

처음 사용해봐서 그런지 둘의 규칙사이에서 충돌도 많이 발생해서 모든 파일에 에러가 나는 등 설정에 굉장히 오랜 시간이 걸렸다. 여러명이서 해결하고 난 끝에 사용해 보니, 확실히 ESLint에서 강제하는 컨벤션 규칙에 따라야 했기 때문에 코드가 통일성 있게 작성된다는 것을 느꼈다. 왜 협업에서 컨벤션이 중요한지, ESLint와 Prettier를 사용해야 하는지 깨달을 수 있었던 좋은 기회였던 것 같다. 

오늘 이 밖에도 여러가지 깃 플로우 전략이나, 커밋 컨벤션, 이슈, 풀 리퀘 등 컨벤션 규칙들, 함수 변수 api 네이밍 규칙들을 정해보았는데 생각보다 정말 이런 초기 셋팅 과정이나 컨벤션을 정하는데 엄청난 시간이 걸린다는 것을 깨달았다. 확실히 프로젝트 시작 전에 기획이나 이런 초기 셋팅을 하는 과정에서 하루 종일 회의를 하고 결정을 하고 소통을 해야한다는 점이 굉장히 힘들다는 것을 다시 깨달았다. 

하지만 규칙적으로 컨벤션대로 코드를 작성하고 나니 유지 보수에 있어서도, 가독성에 있어서도, 일관된 스타일을 유지하는 데에 굉장히 좋다고 느껴져 앞으로도 이렇게 협업에서 필요에 의해 적절히 컨벤션 규칙을 정하여 관리하는 것이 좋겠다는 생각이 들었다.