플러그인 라이프사이클
플러그인은 정의된 라이프사이클을 거칩니다. 설치, 동의, 활성화, 활성 상태, 마지막으로 정리입니다. 모든 전환은 호스트가 강제합니다.
설치
설치는 플러그인 관리자를 통해 이루어집니다. 제한된 .stplugin ZIP
아카이브 또는 공개 저장소 링크(github.com 또는 gitlab.com, HTTPS
전용)를 설치할 수 있습니다. 호스트는 git 바이너리를 절대 호출하지
않습니다. 저장소 아카이브를 내려받아 ZIP과 정확히 같은 검증을
통과시킵니다. 경로 탐색, 심볼릭 링크, 실행 가능 페이로드, 크기,
매니페스트 필드, 진입점, 권한입니다. 설치는 원자적이며 오류 시
롤백됩니다.
패키지에 의존성이 있는 package.json이 포함되면 내장 해석기가 npm
레지스트리에서 설치 스크립트를 실행하지 않고 가져옵니다. 가능하면
의존성을 번들하세요. 해석기는 합리적으로 번들할 수 없는 무거운 WASM
라이브러리를 위해 존재합니다.
동의
검증 후 플러그인은 needs-consent 상태로 들어갑니다. 사용자가 요청된
모든 권한을 확인할 때까지(그리고 npm 의존성 목록이 있으면 검토할
때까지) 그 상태로 유지됩니다. 이 단계에서는 어떤 진입점도 실행되지
않습니다. 전체 모델은 권한을 참조하세요.
활성화
활성화는 두 단계 작업입니다.
- 백엔드 및 레거시 등록이 먼저 시작됩니다.
- 프론트엔드 진입점이 로드되고 API를 받습니다.
활성화가 중간에 실패하면 호스트는 부분 등록을 롤백하고 로드 실패를 기록합니다. 실패한 활성화는 반쯤 등록된 표면을 남기지 않습니다.
활성 런타임
활성 상태에서 플러그인이 만드는 모든 등록 — UI 표면, 라우트, 이벤트
구독, i18n 리소스, 알림, 프로바이더, 토크나이저, 컨텍스트 전략,
사후 처리기 — 은 런타임이 수집합니다. 플러그인은 deactivate()에서
자체 리소스를 관리할 수도 있습니다.
정리
비활성화, 세이프 모드, 삭제, 크래시, 애플리케이션 종료 모두 호스트가 강제하는 정리를 촉발합니다. 런타임은 수집된 등록을 역순으로 처리하며, 보장은 엄격합니다. 플러그인이 비활성화된 후에는 아무것도 남지 않습니다.
- 이벤트 핸들러나 구독이 없습니다.
- 타이머가 없습니다.
- DOM 노드가 없습니다.
- 마운트된 라우트가 없습니다.
- 백그라운드 요청이 없습니다.
- 등록된 프로바이더, 토크나이저, 전략이 없습니다.
플러그인 자체 deactivate()가 던진 오류는 필수 정리를 취소하지
않습니다. 호스트는 추적하는 모든 것을 여전히 처리합니다. 정리는
멱등이며, 두 번 호출해도 효과가 없습니다.
업데이트
업데이트는 패키지를 원자적으로 교체하고 현재 활성화 상태를 유지합니다. 예외가 하나 있는데, 새 매니페스트가 권한을 추가하면 런타임이 즉시 비활성화되고 사용자가 새 권한에 동의할 때까지 비활성화 상태로 유지됩니다. 이전 버전으로 롤백하는 것은 그 버전을 다시 설치하는 것으로 이루어지며, 플러그인 스토리지의 사용자 데이터는 양쪽 방향 모두에서 유지됩니다.
크래시 처리
백엔드 플러그인은 자체 프로세스에서 실행됩니다. 프로세스가 크래시하면 호스트는 해당 플러그인의 모든 등록을 제거하고 실패를 보고합니다. 크래시된 플러그인은 고아 라우트나 이벤트 구독을 남길 수 없습니다. 그것들은 프로세스가 아니라 호스트가 소유하기 때문입니다.
이러한 보장을 가능하게 하는 보안 모델은 샌드박싱, 라이프사이클을 구동하는 매니페스트 필드는 매니페스트를 참조하세요.