카카오테크캠퍼스 2기 | STEP2 | 3일차(24-06-26) 회고

 

⭕ 카카오테크캠퍼스 2기 | STEP2 | 3일차(24-06-26) 회고

📝 tsconfig.json

• tsconfig.json을 파일에 관하여, 문제가 생겼을 때 검색해서 나온 대로 설정했을 뿐, 정확히 무엇을 하고 있는지 이해하지 못했다. 🤷‍♂️

---

tsc 사용하기

• tsconfig.json을 만들지 않고도 tsc를 사용할 수 있다는 사실을 알았다. tsc 명령어를 통해 원하는 .ts 파일을 .js로 컴파일할 수 있었다.

$ tsc hello.ts

 

• tsc는 tsconfig.json 파일 없이도 바로 사용할 수 있었다. 그렇다면 왜 tsconfig.json을 설정해야 할까? 🤔 매번 명령어에 옵션을 주는 것이 번거롭고, 프로젝트에서 일정한 설정을 유지하기 위해서였다.
• vscode는 기본적으로 TypeScript에 대한 IntelliSense를 지원한다. 이 IntelliSense가 .ts 파일을 인식하는 방법을 제어하기 위해 tsconfig.json을 작성해야 했다. 여기서 주의할 점은, vscode의 TypeScript IntelliSense와 tsc는 서로 별개라는 것이다. vscode는 IntelliSense를 제어하기 위해 tsconfig.json을 사용하고, tsc는 TypeScript를 JavaScript로 컴파일할 때 tsconfig.json을 사용하는 것이다.
• vscode는 TypeScript 프로젝트 디렉터리의 루트에 반드시 tsconfig.json을 넣어야 하며, 이를 별도로 설정할 수 있는 방법을 제공하지 않는다. 그러나 tsc는 --build 옵션을 통해 원하는 설정 파일을 지정할 수 있다. 즉, vscode 에디터에서는 에러가 나오지 않더라도 tsc를 통해 컴파일할 때 에러가 발생할 수 있고, 반대의 상황도 발생할 수 있다는 점을 반드시 인지해야 한다. ⚠️
• 또한 중요한 점은 babel은 .ts 파일을 처리할 때 tsconfig.json을 전혀 참조하지 않는다는 것이다. tsconfig.json에 무엇을 작성하든 babel이 TypeScript를 JavaScript로 변환할 때는 영향을 주지 않는다. tsconfig.json은 vscode의 IntelliSense를 제어하기 위한 것이고, babel이 TypeScript를 처리하는 방식을 제어하려면 babel.config.json을 통해 설정해야 한다.

---

tsconfig.json 설정

tsconfig.json을 설정하는 이유는 크게 두 가지였다. tsc를 사용하는 이유는 .ts 파일을 .js로 변환하기 위해서였기 때문에, tsconfig.json 설정은 전체 TypeScript 프로젝트의 최종 결과물이 어떻게 변환될지를 결정하기 위함이었다.

1. vscode의 IntelliSense가 TypeScript를 처리하는 방법을 제어하기 위해서
2. tsc가 TypeScript를 컴파일하는 방법을 제어하기 위해서

• 첫 번째 이유는 vscode에서 잘못된 코드를 작성하지 않도록 방지하기 위함이다.
• 두 번째 이유는 실제 출력물의 형태를 결정하기 위함이다.

---

 

상위 속성 (파일을 선택하고 제외하는 설정)

• include : 컴파일할 파일 경로 목록을 지정
• exclude: 컴파일에서 제외할 파일 경로 목록을 지정

---

compilerOptions 속성 (컴파일러 옵션 지정)

• 타입스크립트로 기본 프로젝트를 진행할 때, 다음과 같은 기본 설정을 사용하는 것이 적절한가요?
• target: 컴파일될 ECMAScript 버전을 명시합니다. ES2015을 권장합니다.
• baseUrl: 모듈 해석에 사용할 기준 경로를 지정합니다.
• module: 모듈 시스템을 지정합니다. 브라우저에서는 ESNext를 권장합니다.
• moduleResolution: 모듈 해석 방식을 지정합니다. Node를 권장합니다.
• esModuleInterop: ESM 모듈 방식과의 호환성을 활성화할지 여부를 지정합니다. true를 권장합니다.
• isolatedModules: 모든 파일을 모듈로 컴파일하고, import 및 export 키워드 사용을 필수로 할지 여부를 지정합니다. true를 권장합니다.
• lib: 컴파일에서 사용할 라이브러리를 지정합니다.
• strict: 더 엄격한 타입 검사를 활성화할지 여부를 지정합니다. true를 권장합니다.

 

📝 Daily Scrum 이후

커밋 메세지

• 오늘은 커밋 메시지에 대한 여러 가지 질문이 있었다. 📝 스스로도 커밋을 어느 정도 단위로 해야 하는지, 초기 설정도 커밋해야 하는지에 대한 궁금증이 있었다.
• 나도 초기 설정마다 커밋을 했지만, 커밋 메시지의 타입을 설정할 때 chore, feat, refactor 중에서 헷갈렸다. 🤔 tsconfig.json에서 옵션을 추가하는 것이 기능을 추가하는 것이 아니라 타입스크립트를 관리하는 작업이라고 생각하면, chore로 분류하는 것이 맞을지 고민했다. 맞을까요…?
  • [답변] 커밋메세지는 팀만의 컨벤션이라 팀마다의 차이가 있을 수 있고 그 안에서의 약속을 잘 지켜주시면됩니다. 예를들면 저희 팀에서는 init: 이라는 커밋메세지를 만들어서 초기세팅은 모두 init으로 처리합니다! 아래 커밋메세지를 팀에서 사용하신다면 조금 분류하기 어려울 수 있겠네요! 보통 chore는 빌드 수정, 설정 변경, 등등의 기타 수정에 대한 커밋메세지를 사용하셔서 chore 메세지를 어떤 경우에 사용할 것인가? 부터 짚고 가시면 좋을 것 같아요!
• 특히, 2차 과제 피드백에서 "주석의 경우 comment 머리말을 사용하는 것이 좋습니다."라는 지적을 받았다. 💡 이 점을 더 주의해서 발전해야겠다고 다짐했다.
• 커밋 메시지의 유형 (https://gist.github.com/stephenparish/9941e89d80e2bc58a153)
  • ✨ feat: 기능 추가
  • 🐛 fix: 버그 수정
  • 🔨 refactor: 코드 리팩토링
  • 🔧 init: 초기설정 / chore: 유지 보수
  • 📚 docs: 문서화 / comment: 주석 추가
  • 💅 style: 포맷팅, 세미콜론 누락 등
  • 🎨 design: 디자인 (스타일과는 구분)
  • 🧪 test: 누락된 테스트 추가

 

😋 Today 회고

• VSCode 확장 프로그램의 다양한 기능들 🛠️, 예를 들어 코드 정렬, 아이콘, AI 지원 등이 매우 편리해 보였기에 무작정 많은 것을 설치했었다. 그러나 직접 설정이 필요한 확장 프로그램을 이번에 처음 설정해 보았다. Step1에서는 해야 할 공부량을 제대로 파악하지 못해 학습을 자주 미루곤 했다. 하지만 Step2는 Requirements에 따라 해야 할 일들을 체계적으로 정리하고(되어 있고) 📝, 매일 단계적으로 학습할 수 있게 되니 나에게 더 적합하다는 것을 느꼈다. 🎯

 

➡️ 참고 링크

https://velog.io/@sooran/tsconfig.json-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%95%8C%EA%B3%A0-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0

{ tsconfig.json } 제대로 알고 사용하기

https://velog.io/@_jouz_ryul/ESLint-Prettier-Airbnb-Style-Guide%EB%A1%9C-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

ESLint & Prettier, Airbnb Style Guide로 설정하기