프론트엔드
Module Federation: singleton이면 당연히 하나겠죠?
두줄요약
Module Federation에서 singleton만으로 해결되지 않는 React·Context 중복 원인을 분석했습니다. 런타임, import 경로, pnpm 설치 사본까지 점검 기준을 제시합니다.
구조와 흐름
- Module Federation의 host·remote 독립 빌드와 런타임 조립 구조
- React 인스턴스 분리 시 훅 내부 상태 불일치로 인한 Invalid hook call
- 다중 entry 런타임과 모듈 캐시 분리로 인한 Context 객체 이중 생성
해결 방법
- React·React DOM·디자인 시스템 등 직접 공유 인스턴스가 필요한 의존성의 singleton 설정
- host 내부 모듈 중복 실행 문제에 대한 runtime chunk 통합
- 서브패스 import 요청 경로의 별도 shared 키 등록
- pnpm peer dependency 버전 정렬과 카탈로그 기반 중복 설치 방지
선택 이유
- remote가 host 인스턴스를 직접 사용해야 하고 래퍼 훅으로 우회 불가능한 경우만 싱글톤 적용
- React Query는 remote 자체 Provider 필요성 때문에 공유 제외
- 아이콘 패키지는 초기 청크 증가와 tree-shaking 제한을 고려해 공유 제외
주의할 점
- shared singleton은 host와 remote 간 의존성 공유 대상이며 host 내부 모듈 중복 해결 수단 부재
- shared 키와 실제 import 요청 경로 불일치 시 별도 사본 로드 가능성
- shared가 여러 설치 사본을 병합하지 않고 키·버전별 사본 하나만 선택하는 제약
