제 문제는 아니였지만 옆의 크루가 Netlify 배포하는 도중 webpack 빌드하는 과정에서 module을 찾지 못하는 에러가 발생했어요.
분명 로컬에서는 문제없이 빌드가 되었거든요.
에러를 읽어보니
UserInfo.ts을userInfo.ts로 생각하고 찾고 있더라구요. 혹시 몰라서 기존UserInfo.ts파일을 소문자 네이밍으로 변경하고 했더니 문제가 해결되었습니다.
왜 그랬던걸까요?🤔🤔
의문1) 로컬에선 빌드가 잘 되더니...
의문2) 갑자기 왜 자기 맘대로 UserInfo를 userInfo로 생각했을까? 혹시 대소문자 구별 못하는 건가?
vscode에서는 import를 할 때 대소문자가 달라도 괜찮아요. 관대합니다.

login-header를 Login-header로 변경했는데도 문제없이 웹에 반영됩니다.webpack도 마찬가지로 아무 문제없이 빌드되고 웹에 반영됩니다.

webpack --watch는 실시간으로 파일의 변화를 감지해 자동으로 빌드해줍니다.
근데... 맹점이 있습니다😢😢😢
webpack --watch는 userInfo 👉 Userinfo로 변경을 해줘도 변경을 감지하지 못하는거죠!
변화를 감지하지 못해서 빌드가 안되고 당연히 웹에도 실시간으로 반영이 안 되는 거죠...
에러가 발생했던 크루는 처음에 카멜케이스(userInfo)로 네이밍을 작성했을거예요.
이후에 export를 해야겠다 생각해서 파스칼 케이스(UserInfo)로 네이밍을 변경했을 것 같아요.
하지만 이 변경 사항을 감지하지 못한거죠. 그래서 에러가 발생했다고 생각합니다.
camelCase (카멜 케이스)
PascalCase (파스칼 케이스)
snakecase (스네이크케이스)
kebab-case (케밥-케이스)
JavaScript
파일명
URL
case-sensitive-paths-webpack-plugin을 사용하면 case 실수가 있을 경우 build 과정에서 전부 알려줍니다. 완전 맞춤형 해결방법이죠? 그럼 이런 생각이 들죠?
굳이 네이밍을 대문자가 섞인 파스칼케이스나 카멜케이스를 할 필요가 없을 것 같다는 생각이 들어요.
소문자만 사용하면 운영체제 상관없이 변경된 파일명을 제대로 추적할 수 있을 것 같거든요.

npm 패키지들의 이름을 유심히 살펴 보면 모두 케밥케이스를 사용해요. 그리고 여태까지 단 한번도 대문자가 들어간 패키지 이름을 본 적이 없어요.
모듈을 불러올 때 위에서 언급했던 대소문자 이슈가 있었기 때문이 아닐까요?
자판기 미션의 리뷰어이셨던 월터님께도 네이밍 관련해서 질문을 남겼습니다.
(윈도우, 리눅스, 맥OS 가 혼재되어있는 30명 규모였던 팀에서) 클래스나 모듈같은 경우는 파스칼케이스를 사용하고 그 외에는 카멜케이스를 사용하고 있습니다.
다만 "케밥케이스가 안좋냐?" 라고 하면 절대 아니고 그냥 팀의 선호나 언어, 프레임워크의 권장에 따라 컨벤션이 생기는 것 같습니다.
카멜케이스와 파스칼케이스를 사용해왔었습니다ㅎㅎ 다양한 환경에 따라 네이밍이 정해질 것 같네요.https://jeonghwan-kim.github.io/dev/2020/05/18/filename.html