Quartz 4.0
- 백엔드로 쓰던 hugo에 더의상 의존하지 않고 npm에 있는 라이브러리를 사용한 것 같다.
- quartz를 분석해서 개조하려고 hugo에 대해서 조사하고 있었는데.. 크게 바뀌어버렸다.
- 그런데 이렇게 바뀐 게 좋은 것 같다.
- 설정하기가 매우 편해졌다. github action도 잘 설정해줘야 하고 hugo 같은 디펜던시 때문에 local로 돌릴 때 윈도우가 아니면 설정하기 까다로웠는데, 이제 이런 문제는 없어졌다.
- 기존에는 깃허브 페이지에서 graph view 가 잘 안 되는 문제가 있었다. 원인을 찾덛 중이었는데, 암튼 4.0에서는 해결됨.
- 이전에는 obsidian으로 content 폴더를 관리하려고 obsidian vault를 깃허브로 싱크하고 submodule로 quartz 안에 가져다 놨다. 이렇게 하면 github action에서 push시 submodule 내용을 참조하라고 명령을 줘야 하고 특히 그 리포가 프라이빗 리포면 귀찮게 설정해야 했는데, 이제는 vault로 쓰는 디렉토리를 symbolic link로 참조할 수 있다. 다만 이렇게 외부에서 symlink로 내용물을 가져올 때는 뭔가 다른 방식으로 처리하는 것 같다. 어떻게 처리하는지는 아직 정확히 모른다.
- 맥에서 몇번이고 리포 삭제 후 다시 클론하는 짓을 한 7번은 한 것 같은데… 내부적으로 어떻게 돌아가는지를 정확히 모르고 이런 문제가 생기니까 무식하게 해결할 수 밖에 없다.. 그냥 웹개발 배워야겠다.
- 다만, 나느 github를 통해 여러 PC에서 vault를 동기화하고 있었고, 이 vault를 submodule을 통해 quartz/content 안에 가져다 놓고 있었는데, quartz 4.0에서는 quartz 외부에 있는 content/ 를 symlink해오는 방식을 지원하면서 뭔가 자체적인 처리법을 마련해 놓았는데, 이게 내가 쓰는 방식이랑 충돌이 있는 것 같다.
- 또 맥북에서 내장 SSD를 두개로 파티션해 윈도우 C, D 드라이브처럼 사용하고 있었는데, D드라이브처럼 쓸 파티션을 exFAT으로 포맷하는 바람에 그 파티션에서는 파일을 만들기만 하면 앞에 ._ 가 붙은 파일이 자동으로 생긴다. (맥OS만 이런덴다) 이게 또 quartz 내부적으로 처리하는 로직이랑 충돌이 있는 것 같다;; 하여간 사소한거라도 그냥 넘기면 꼭 나중에 크게 두들겨 맞는다. 맥북 내장 SSD 포맷할때는 그냥 APFS로 하자…
- 일단은 지금 잘 모르는 상태에서 quartz 리포를 다른 컴퓨터에 받지 말자. 일단 맥북으로만 관리하자.. 맥북에서 content 디렉토리로 쓸 디렉토리를 symlink를 해서 받아왔는데, 새로운 컴퓨터에서 클론받았을 때 거기에 symlink할 경로가 없으면 꼬이는 것 같다. 일단은 맥북에서만 하자.
node
npm
- npm i 이거는 무엇을 하는 건가
npm i
### npx