현재 시각은 23시 58분. Fedify에 NestJS를 지원한다고 온갖 삽질을 하다가 마지막을 보고 있는 시점에서 뭘할까 고민하다 가만히 있기는 좀 그래서 끄적이는 의식의 흐름대로 쓰는 글....

맥락이 싹다 휘발되기전에 내가 어떻게 우여곡절을 겪었는지를 좀 러프하게 요약해보자....

• Fedify 프로젝트를 NestJS 에서도 쓸 수 있도록 Fedify 모듈을 만들려고 했던 것에서부터 불행이 시작됨.

• 애초에 NestJS는 CommonJS 기반이고 Fedify는 ESM 모듈만 지원했어서, 이걸로 사용할 수 있녜마녜 하는 얘기가 오가는 중에 Node 22 버전에서 NODE_OPTIONS=--experimental-require-module 환경변수 걸면 esm 모듈을 가져올 수 있다는 사실을 알게됨.

• Fedify 프로젝트에 포함된 라이브러리로 넣기 이전에, 가설검증은 해봐야겠어서 기존에 NestJS 기반으로 만들려고 벼르고 있던 프로젝트에서 가설검증을 시도함

• 가설 검증 자체는 성공적이고 스무스했음. Fedify microblogging 예제를 돌릴 정도는 돌아갔던 것 같음.

• 하지만........ Fedify로 통합하는 과정이 문제가 있었는데... Fedify에 돌아가는 코드를 옮겨놓고, 그 코드가 의도하는대로 잘 뽑히는지가 문제였던 것이다.

• 예를 들면, NestJS는 Typescript 생태계에서는 거의 deprecated된 것으로 취급하는 Decorator 문법을 쓰고 있는데, deno 런타임에서는 지원안하는것은 물론이고, 패키징을 하는 것 자체는 성공했으나 npm 패키지를 가져다 쓰는 입장에선 계속해서 런타임 에러가 뜨는 것. 데코레이터 문법의 경우엔 tsconfig 파일을 또 별도로 수정해서 어떻게든 코드가 뽑히게 했음.

• 그래서 node_modules 를 직접 까보면서 코드가 어떻게 뽑히는지 직접 두눈으로 확인해보기도 하고, 민희님 도움 받아서 pnpm prepack 커맨드로 tgz 파일 만들어서 그걸 package.json에서 가져다 쓰는 것도 어쩌다보니 하게 되고... 패키징은 제대로 되었는데 왜 import 오류가 다시 뜨는가 하고 봤더니, 처음으로 돌아가서 NODE_OPTIONS 환경변수 문제였고. commonjs/esm 둘다 js 아웃풋이 나오도록 세팅하는 것도 해보고, 패키지 퍼블리시까지 겨우 성공

• 그러다가, 다시 왜 안 돌아가지하고 봤는데... 처음에 돌아가던 코드에서 좀 정리를 하다보니 안 돌아가게 된 케이스도 있었고, 어떤 부분은 NestJS 내부 구현(Express)을 몰라서 계속 똥볼을 찬 케이스도 있었고, 몇시간을 심연을 들여다 봤던 것 같다...

패키징하면서도 오류 터져서 빌드깨지는거만 체감상 한 10~15번 정도한 것 같은데 머리에 스팀 나는 줄 알았음...

이젠 된다... 진짜 험난한 여정이었다...