[Node] class 혹은 function의 file path를 찾아보자

가장 쉬운 방법은

console.log(__filename);
console.log(__dirname);

 

__filename과 __dirname을 이용해 찾는 것이다. 하지만 이 방법은 그 class와 function의 내부에 직접적으로 선언해주어야하며, 만약 해당 class나 function을 export해서 외부에서 써야하는 상황이라면 __filename과 __dirname을 이용해서는 알 수가 없다. 외부에서 __filename과 __dirname을 사용하면 외부의 파일 경로가 나오게 된다.

따라서 이는 모든 상황에서 적용될 수 없으며, 알고자 하는 class나 function을 반드시 건드려야하는 큰 단점이 있다.

(사실상 쓸 수 없음)

 

실제로 광범위하게 적용할 수 있는 방법에는 3가지 정도가 있다.

 

---

1. error stack

console.log(new Error().stack);

단순무식(?)하게 에러를 발생시키고 stack을 찍어보면 알 수 있다.

위 이미지에서 알 수 있듯 ~/custom-error/index.js에서 에러가 발생했다는 것을 알 수 있다. 그러나 이는 모든 상황에서 적용될 수 없으며, 크로스 플랫폼 이슈가 발생할 수 있다.

 

장점

1. 쉽다.

2. 3가지 방법 중 가장 빠르다.

 

단점

1. general 하게 사용하지 못할 가능성이 있다.

 

속도가 빠르고 구현이 간단하기에, 엄격하게 상황 통제가 가능한 상황에서 file path를 알아야한다면 추천하는 방법이다.

 

 

2. inspector module

노드로 debugger를 실행시켜보면 [[FunctionLocation]]이라는 프로퍼티를 볼 수 있다. 이게 바로 file path다.

그럼 이걸 접근할 수 있는 방법은 없을까?

import * as inspector from 'inspector';

const session = new inspector.Session();
session.connect();

노드의 inspector 모듈을 이용하면 코드에서 디버거 세션을 열어 접근할 수 있다. 여기에는 몇가지 장단점이 있는데, 만약 general하게 사용하고 싶다면 그 조건을 가장 충족시킬 수 있는 방법이다. 그러나 문제는 inspector 모듈에 대한 진입장벽이 있고, 그 구현이 간단하지만은 않다.

 

장점

1. Node 런타임 환경의 공식 모듈이므로 크로스 플랫폼을 완벽 지원하고, general 하게 적용할 수 있다.

 

단점

1. 익숙치 않은 inspector 모듈.

2. async await이 강제된다.

3. 2번 단점 항목에서 알 수 있듯, 3가지 방법 중 가장 느리다.

 

문제는 비동기로 동작하게 되서 사용하기가 다소 곤란할 수 있다.

 

 

3. 노드 V8 엔진에서 접근

V8 엔진에서도 두 가지 방법으로 나눠진다.

첫 번째는, [[FunctionLocation]]에 직접 접근할 수 있다. 그러나 공식 API가 아니기 때문에 약간의 불편함(에러 스택 트레이스를 굳이 해야하나하는 그러한 종류의 불편함)이 가슴 어딘가에 느껴질 수 있다.

두 번째는 ScriptOrigin 객체에 접근해서 알 수 있다. 이는 공식적으로 제공되는 객체이기에 마음 한 켠의 언짢음도 없다!

그러나...

예? V8이요? 어떻게 하는거죠?

 

그래서 라이브러리를 만들었습니다!

 

https://www.npmjs.com/package/function-location

function-location

 

장점

1. 준수한 속도.

2. general한 사용성.

 

단점

1. 라이브러리를 찾아보자.

 

 

---

 

이 글의 내용은 약간의 과장과 유머..를 포함하고 있으며 라이브러리도 직접 개발하고 퍼블리싱했지만, 3번째 방법을 추천하지는 않습니다.

왜냐하면 V8에 접근하기 위한 네이티드 애드온은 바이너리 파일이고, 그만큼 단순 코드text에 비해 용량이 좀 있는 편입니다. 범용적인 라이브러리 사용성을 위해 크로스 플랫폼을 지원하고, 따라서 win, unix 애드온이 각각 들어가있어서 그만큼 불필요한 용량을 차지합니다. 약 169kb를 차지하는데 이 정도는 심적으로 괜찮다면 사용해볼만할지도?

개인적으로는 async await이 걸리는 불편함을 감수하실 수 있다면 2번째 방법을 추천합니다.

 

 

추가적으로, 네이티브 애드온은 C++로 작성되었는데도 불구하고 3번이 1번 방법보다 느린 이유는 네이티브 애드온을 왔다갔다 하는 것 자체의 오버헤드가 존재하기 때문입니다.