로컬에선 잘 되는데... 원격지에서 클론한 레포지토리에서 특정 파일에 대해 module not found가 뜬다면?

Case-Sensitive 주의

그렇다면 무조건 대소문자 문제가 아닌지 확인하도록 하자.

하필이면 딱 한 글자, i와 I의 차이로 인해 3시간이 넘도록 개 뻘짓을 해버렸다. 부디 이 글을 읽고 향후에 이런 개떡같은 운명에 마주치지 않길 바란다.

git config core.ignorecase

일단, 첫 번째로 할 건 case-insensitive OS, 특히 윈도우를 사용 중일 때 레포지토리 루트에서 다음 명령어를 실행하는 것이다.

git config core.ignorecase false

그렇지 않으면 나처럼 일을 두 번 하게 될 것이다.

위 git config를 적용하면, git이 이후 해당 레포지토리 내의 파일의 대소문자 변경을 감지하게 된다. 즉, headerIcon.png 파일이 headericon.png로 변경됐을 때 headerIcon.png 파일은 없어진 것으로 판단하고, headericon.png 파일은 새로 생긴 것으로 판단하게 된다.

이 설정을 선행하지 않고 아래 지침을 따르게 되면 파워쉘 스크립트나 배치 파일로(혹은 일일히 UI로) 파일명을 바꿨다가 다시 원본 파일명으로 돌려야 하게 될 것이다.

Case-Sensitive한 파일명 변경

이제 코드에서 사용하는 경로와 일치하도록 파일명을 변경한다. 예를 들어, 코드에서 import HeaderIconImage from "@images/icons/headericon.png"를 사용한다면 headerIcon.png를 headericon.png로 변경하면 된다.

나 같은 경우에는 다른 개발자의 프로젝트 파일을 그대로 복사해왔는데… 설마 같은 폴더 내의 수십개의 headericon-*.png 파일이 각각 i와 I가 번갈아가며 썼을 줄은 몰랐다. 후… 가능하면 이름 컨벤션은 일치시키도록 하자.

commit 및 원격지 pull, 정상 작동 확인

이렇게 했으면 이제 원격지에서 git pull로 레포지토리를 당겨와서 잘 작동하는지 확인하면 된다.

의문점

신기한 것은, Windows -> Linux 일 때 뿐 아니라 Windows -> Windows일 때에도 같은 문제가 생겼다는 것이다. 둘 다 case-insensitive한 운영체제인데 도대체 뭐가 문제였을까? SSH에서 작업한 게 영향이 있었던 것일까?

지금은 시간이 많지 않아 다시 테스트 할 용기는 없지만 언젠가 여유가 되면 한 번 확인해보고 싶은 부분이다.