1. type과 interface를 구분 할 수 있으면서,
2. 타입 또는 interface인지 아니면 그냥 객체가 할당된 함수인지 확인 할 수 있으면 좋을 것 같습니다.
3. 더불어 차차 의미상 어떻게 나눌지도 정하면 좋겠습니다. 이것은 정답이 있는건 아니라고 알고있습니다.

현재는 오락가락 합니다.

경우 1. I***
경우 2. ***Type

api/todo/types.ts:1: export interface createTodoType {
api/auth/types.ts:1: export interface postSignType {
lib/hooks/useValidation.tsx:4: interface ISignForm {
lib/routerMeta.ts:1: export interface IRouterMeta {
pages/TodoPage/types.ts:3: export interface ITodo {
pages/TodoPage/types.ts:10: export interface ITodoForm {
components/HOC/ProtectedRoute.tsx:6: interface IProtectedRoute {

routerMeta 파일은 라우터에서만 사용하는 타입 파일입니다. 그런데 갈 곳을 잃고 lib/ 에서 헤메고 있는 것 처럼 보입니다. 아니면 어떤 이유가 있을까요?

router폴더 안에 routerMeta.d.ts 또는 router-meta.d.ts 좋을 것 같습니다.

/src/api/apiClient.ts

line : 10 const host = 'https://pre-onboarding-selection-task.shop';

이것도 상수인 것 같은데 대문자로 바꾸는 게 맞을까요 아니면 constant에 가야 할까요?

혹은 어떤 다른 이유가 있는걸까요?

근거 1. .tsx 와 .ts로 구분하는 것 보다 눈에 잘 띄고 명확합니다.

근거 2. tsc 컴파일 결과로 만들어지는 .d.ts파일과 직접 만든 .d.ts파일이 구분되어야 할 이유가 없는 것 같습니다.

근거 3. 관련 검색 결과

<== 요약 [ .d.ts 쓰되 이름은 알아보기 좋은 걸로 적당히 지어라 ]

<== For filenames that contain type definitions or interfaces in TypeScript, the convention is to use a .d.ts extension. This extension indicates that the file contains only declarations, without any executable code.

For example, if you have a file that contains some interface and type definitions for your application, you could name it as follows:

perl
Copy code
my-interfaces.d.ts
In this example, the filename is "my-interfaces.d.ts", which follows the convention of using PascalCase for the filename and adding the .d.ts extension to indicate that it contains only declarations.

It's worth noting that you can use any filename you like for your type definition files, as long as they follow the .d.ts convention to indicate that they contain only declarations. However, using a descriptive filename that reflects the contents of the file can make it easier to understand the purpose of the file, especially when working with larger projects.

==> 위 지문에 나온 것 처럼 적당한 이름에 PascalCase.d.ts 어떨까요?

(번복 죄송합니다. 머리가 빨리 빨리 안돌아갔습니다.)

저희 프로젝트 root 경로에서,

npx prettier --write .
npx eslint --fix .

이렇게 한번 진행 해 주시면 좋을 것 같습니다. 참고로 npx는 npm으로 설치하여 사용하는 패키지들을 로컬에 설치하지 않고 최신버전으로 실행 만 하는 명령어입니다.

일부 팀원(지금은 저 한명 뿐이긴 하지만) 때문에 꼭 필요하지도 않은 파일을 모두가 가지고 있어야 한다는 것은 썩 좋은 일은 아닌 것 같습니다. 게다가 그 문제가
npx 명령 두 번으로 해결된다면 더욱 그런 것 같습니다.

이미 해결 된 문제지만 쫌 죄송하기도 하고, 어쩄든 더 좋은 방법인 것 같아 제안을 드려 봅니다.

주제

과제 피드백을 보시면 리드미에 대한 피드백을 볼 수 있습니다. 좋은 리드미를 작성하기 위해 넣을 내용을 고민하면 좋을것 같습니다. 제가 생각한 내용은 아래와 같습니다. 추가 아이디어가 있으시면 말씀해주세요.🙇🏻‍♂️

필수 내용

• 제목, 소개 글
• 배포링크, 기능 구현 목록 링크
• 기능
• 기술 스택
• Getting Started
• Demo
• 과제 진행 방법
  • 어떻게 동료 학습/협업을 하였는지 설명 (작업 프로세스 개요??)
  • 분기별 베스트 프렉티스/추가사항 그리고 선정한 이유/추가한 이유 + 각 PR링크

근거 1. 팀장님이 아니시더라도 한 명 뿐이라면 예상 밖의 상황에 빠르게 대응하기 어렵습니다.
근거 2. 인원이 많고, 시간이 짧고, 협업 경험도 적은 많큼 회의에서 모든 내용이 다 합의가 된다고 보기 어렵습니다. 차근차근 보다보면 다른 좋은 의견이나 유익한 비판이 나올 수 있을 것 같습니다.
저같은 경우는 화면 공유로 설명 해 주시는 것들을 한번에 다 이해하기가 쉽지 않더라고요. 커밋 기록 보면서 차근차근 보면 나름 잘 이해가 되는데 말입니다.
근거 3. (근거 2에 이어서) 따라서 pull request의 리뷰 기능과 다수 동의에 의한 merge 확정이 기능적으로나 (협업)체계로 보거나 좋다고 생각합니다.

한편, 앞으로 익숙 해 질 수록 모두 모여서 하는 회의 보다도 시간적으로도 더 효과적일 수 있을 것 같습니다. 시간을 딱 정해두고 리뷰를 마치는(동의/비동의) 식으로 한다던가 하면 말입니다.

webhook test