어쩌면 건들지 말았어야 할 물건이였다 #
VuePress의 알파릴리즈가 게시된 상황에서 이미 npm install vuepress를 치던 날 말렸어야 했다. 알파릴리즈가 게재되었다며 얼른 좋다고 블로그 시작할 수 있겠구나 싶어서 하던 날 말렸어야했다. 하지만 내가 공중전화 박스에서 날라다니는 사람도 아니고, 저 어딘가 일본에서 거주하는 매드사이언티스트를 자칭하며 백의를 입지도 않기에 말릴수 없었다.
그렇게 내 삽질은 시작되었다. 삽질 한 기념으로 삽질 한 내역좀 적어볼까 한다.
삽질의 첫시작, alpha.0 #
음 여긴 그냥 혼돈이다 혼돈.
존재하지 않는 문서(Documentation) #
정확히는 존재는 했다, 존재는 하는데 그냥 속빈 강정이라고 보면된다. next 브랜치 작업을 한명이서 도맡아 진행하다보니 어쩔수없이 생긴 결과이기도 하지만, 그래도 여기까지는 애정이 엄청나게 넘쳐나서 그냥 소스 찾아보면서 하자 싶어서 저장소 관리자인 ulivz가 제작한 blog 예제(egoist)와 테마를 보고 참조했다.
근데 커스텀 테마에 대한 내용이 존재하지가 않네? 여기서 머리를 싸메어서 내린 결론.
- 커스텀 테마를 만들기 위하여 저장소를 만드는 방법 외의것이 있을것이다.
- 그럼 어떻게해야되냐?
- 소스를 뜯어야지!
열심히 뜯고 찾은결과 .vuepress 폴더에 theme와 components가 들어가면 자동으로 포함시켜준다는걸 알고 성급하게 제작을 진행했다.
그리고 하나 더, CSS Pre-Processor들의 webpack 설정이 config 안에서 가능하다는걸 알게되었다. 문서가 너무 빈약해서 알수도 없었다. (이건 나중에 구글로 검색하다보니 우연히 문서에 나오더라)
Webpack의 module 문제 #
이건 전혀 예상치 못한 문제였다.
커밋메세지를 잠깐 빌려 이야기하자면 webpack에서 존재하는 이상한 문제라는데, VuePress의 저장소 안에 ClientComputedMixin이 서버와 클라이언트 동시 사용함에 따라 ES Module(import, export)를 CommonJS module(require(), module.exports)로 변경하였지만, 작동은 하되 Webpack에서 불러오질 못한다는거다. 해당 커밋 (opens new window)
이상하다. 여튼 자세한 해당 내용은 Webpack 저장소에 적혀있는 이슈 (opens new window)를 참고하면 된다.
이슈 리포트를 남겼더니 저장소 관리자가 꽤 빠르게 처리해주었다.
두번째 삽질, alpha.1 #
컴포넌트 이름 문제 #
이 문제는 3시간 전까지 겪던 문제다.
레이아웃을 총괄하는 컴포넌트 파일명을 Layout.vue로 지정했어도 단지 큰 문제는 없으리라 생각하고, vue파일 안에 script안에 name을 지정하여 별도로 인식할 수 있게 했더니. 빌드가 안된다.
정확히는 개발모드(vuepress dev)로의 접근은 가능한데 빌드(vuepress build)가 안된다.
이거 모르고 뭘했냐면
- SCSS 적용문제인가 싶어서 레이아웃의 모든 SCSS코드를 삭제했었다.
- npm 설치가 삐끗난건가 싶어서 재설치를 몇번이고 하고 지우고 하고 지우고 하고 지우고 반복했다.
- Windows Subsystem으로 설치한 Ubuntu에서는 Vue SSR쪽에서 오류가 나길래 그쪽의 코드를 뜯었다. 근데도 문제가 없다.
- 결국 블로그를 파일 하나하나부터 다시 만드는 작업을 진행했다.
설마가 사실로 바뀌는 순간이였고, 멘탈이 조용히 바사삭 터져나가는게 마음 한구석에서 들려오기 시작했다
Webpack의 상대경로 문제 #
이건 내 잘못이긴 한데 상대경로를 입력해둬서 import 하는곳의 디렉토리가 조금만 삐끗하면 바로 에러가 떴다.
webpack 설정을 뒤져 alias에 @source가 지정되어있길래 해당 alias 지정으로 해결했다.
category, tag 페이지 개발모드에서 확인 불가능 문제 #
현재진행형 문제로써, Github에 올려둔 이슈에서 저장소 관리자마저 감을 못잡는 문제이자(이슈 (opens new window)), alpha.2 버전에서 생기는 문제의 원흉이 된 이슈이기도 하다.
나는 안되는데, 쟤는 된대. 뭐야 이거.
build시에는 페이지는 보이는데, 얼떨결에 불편하게 만들수밖에 없는 상황이 되어버렸다.
세번째 삽질, alpha.2 #
갑자기 뜬금없이 VuePress 저장소의 관리자가 upath라는 라이브러리를 들고와서 path를 대거 변경해버리더니(Windows환경), 작동이 안된다. 멘탈이 제대로 터졌다.
webpack의 Windows OS환경에서의 unix path 인식 문제 #
upath를 npm에서 황급하게 검색해보니 다음과 같이 적혀있었다.
node의 path 모듈에 대해 이러한 사항들을 대체/우회해줍니다.
Windows의 경로 인식자인 \를 unix의 경로 인식자인 /로 모든 결과값을 바꾸어준다
음, 그래 이걸 버그도 체크 못하고 올렸다는건 충분히 이해가 간다. 아마 저장소 관리자가 맥이나 리눅스를 쓰겠지 음 하면서 정신승리를 하고있다가, 갑자기 멘탈이 터졌다. 그렇게 키보드에서 손을 떼고 잠시 쉬러 밖에 나갔다왔다.
그 뒤에 구글링해보니, 해당 이슈는 VuePress에서 생기는 문제는 아니였고, webpack에서 존재하는 문제로 2015년에 이슈가 생겨있던 상태였다. (이슈 (opens new window))
네번째 삽질, Github Pages #
위의 문제들을 겪고 멘탈이 나갈대로 나가있는 상황에서 어찌저찌 빌드를 다 끝내고 블로그 저장소로 커밋을 뙇 올렸더니
24시간이 걸려?
다행히 진짜로 24시간 기다리란 말은 아니였고, 5분에서 10분뒤에 도메인 적용이 진행되고, 10분뒤에 인증서 발급도 완료 되어서 HTTPS 적용이 가능해져 블로그 접속이 가능해졌다.
마지막 삽질, Git #
난 또 vuepress build 명령어로 만든 파일이 다른놈들만 올려주고 Git저장소로 편하게 관리하게 만든줄 알았더니, 다짜고짜 컴파일 전에 파일이 다 지워져버린다.
급하게 스크립트를 급조, publish용 폴더(편의상 dist)를 분리하고 publish 명령어로 컴파일 된 폴더(편의상 compiled)의 내용물들을 dist에 복사한다. 될때까지 계속 시도한다.
리눅스면 cp 와 rm명령어만 기억나는데 윈도우 배치파일은 써본적이 없다. 다행히 구글에 검색해보니 StackOverflow에 나온 내용들이 많아서 살았다. 그런데 또 그냥 커맨드라인에서 잘 되는 git명령어가 배치파일로 실행할땐 안먹힌다.
돌겠네.
결론 #
여기까지가 무사히 깃허브에 블로그를 올린 내 삽질과정의 일련이다. 뭐 그래도 새로운 스택 하나 얻고가지 않느냐 하면 차라리 탑에서 스택쌓는 나서스가 더 효율적이라고 말해줄수 있다. 이 포스트를 다 본 여러분은 행운에 넘치는 분들이라 나같은 삽질은 안했으니 다행인거다.
막상 다 하고 나니 죽여주세요라고 생각은 들었는데, 오픈소스 관리를 이렇게 열심히 정성들여 하는일이 얼마나 더 어려울까 싶을정도의 마음이 들었다. 저장소 관리자의 페이지에는 페이팔 도네이션이 없는데, 꼭좀 만들어줘서 도네이션 해줄수있게 하면 커피값 팁정도는 넣어주고픈 마음이 들었다. (알리페이는 정말 불친절하기 따로없다.)
요즘 운전을 하는데 가족들이 운전을 험하게 한다고 꾸중을 한다.
내 운전이 험해진 이유가 요즘 삽질을 계속 하는 여기에 있지 않을까 또 정신승리를 하고간다.
Comment