Module

개요 tsconfig.json은 TypeScript 컴파일러 tsc의 설정 파일이며 프로젝트를 어떻게 컴파일할지 정의함 TypeScript 코드가 JavaScript로 변환되는 경로에 대한 스위치 보드 역할 수행 TypeScript (.ts) ↓ [ tsc ] ← tsconfig.json이 규칙 제공 ↓ JavaScript (.js)module 옵션 출력되는 JavaScript의 모듈 시스템 선택 모듈 시스템의 변화 요약 없음, 전역 스코프 공유 CommonJS, require/module.exports 중심 AMD, 브라우저 환경 define/require ES Modules, 표준 import/export 주요 값과 용도 commonjs Node.js 구버전 호환 es2015/es6 표준 ESM, 브라우저·번들러 환경 es2020 ESM + dynamic import 사용 환경 es2022 ESM + top-level await 사용 환경 esnext 최신 ESM 기능 추적 nodenext Node.js 16+의 ESM 출력·해석 규칙 반영 node16 Node.js 16의 ESM과 CJS 혼합 환경 대응 같은 코드의 다른 출력 예시 ...

개요 NestJS에서 @Module은 기능 단위 의존성을 묶는 단위이자 DI 경계를 정의하는 컨테이너 개념임 핵심은 imports로 외부 의존성 수입, providers로 내부 의존성 등록, exports로 외부 공개 대상을 결정하는 흐름 이해가 전부임 Module의 imports, providers, exports @Module 선언의 기본 형태 @Module({ imports: [...], providers: [...], exports: [...] }) class SomeModule {} providers 이 모듈에서 새로 생성해 DI 컨테이너에 등록할 대상 목록 @Injectable 클래스들 중심 Service, Repository, Adapter 등 예시 providers: [BatchService, PortFetcher, StoreService, MergeService] imports 다른 모듈이 exports로 공개한 provider를 이 모듈에서 사용하겠다는 선언 예시 imports: [RepositoryModule, HttpModule, LoggerModule] exports 이 모듈 바깥에서도 사용 가능하도록 내보낼 provider 목록 예시 exports: [JSON_REPOSITORY, LogRepository]정리하면 providers는 내부 생성, imports는 외부 수입, exports는 외부 공개 대상 지정임 ...

개요 NestJS을 다루다 보면 ConfigModule.forRoot(), TypeOrmModule.forRoot() 같은 코드를 보게 됨 보통 “이건 전역 설정이니까 한 번만 하면 끝이고 알아서 싱글톤 유지되겠지?“라고 생각하기 쉬움 하지만 forRoot()를 호출한다고 프레임워크가 알아서 물리적인 싱글톤 인스턴스를 강제하는 건 아님 특히 ScheduleModule처럼 사이드 이펙트(이벤트 리스너, 타이머 등)를 유발하는 모듈을 잘못 다루면, 기능이 중복 실행되는 심각한 버그가 터질 수 있음 이 글에서는 forRoot()의 진짜 의미와 내부 동작, 그리고 ScheduleModule 중복 실행 문제가 왜 생기는지 코드로 뜯어보겠음 forRoot()란 무엇인가 forRoot()는 NestJS의 동적 모듈(Dynamic Module)을 생성하기 위해 관례적으로 쓰는 메서드 이름임 ...