플러그인 추가: 세 표면 규칙

"플러그인은 세 곳에 존재하기 전엔 설치된 게 아냐. 셋 중 둘은 조용한 실패 함정이야."

세 표면, 매번

Tauri 플러그인을 올바르게 엮으면 항상 세 파일을 건드려. 체크리스트로 쥐어:

Cargo.toml — Rust 크레이트 의존성(tauri-plugin-store = "2").
lib.rs — 빌더 체인에 등록(.plugin(tauri_plugin_store::Builder::new().build())).
capabilities — permission 부여("store:default").

그리고 보통 더 가벼운 네 번째: 프론트엔드에서 부르면 JS 패키지(@tauri-apps/plugin-store). Cargo 의존성 빠지면 컴파일 안 돼(시끄러움, 쉬움). 빌더 빠지면 플러그인이 아무것도 안 해. capability 빠지면 프론트엔드 command가 permission 에러로 실패해. 셋 중 둘 상태는 조용히 실패해서, 이 규칙을 외울 가치가 있어.

제거도 세 표면이야

규칙은 양방향이야. 플러그인을 제거할 때 세 표면 다 되돌려야 해, 안 그럼 죽은 무게를 남겨: 빌드를 부풀리는 안 쓰는 크레이트, 쓸모없는 걸 등록하는 빌더 줄, 사라진 플러그인의 permission을 부여하는 capability. Cinder가 정확히 이걸 learning으로 기록했어 — 플러그인 빼기는 Cargo 의존성, lib.rs 빌더, 그리고 capabilities 파일을 발맞춰 편집하는 거였어. 추가랑 제거를 대칭의 세 표면 작업으로 대해.

왜 이 설계냐

의식처럼 느껴질 수 있지만, 각 표면이 기본 거부 모델을 섬겨: Cargo 의존성이 코드를 가져오고, 빌더가 코어에서 그걸 활성화하고, capability가 '그래, 프론트엔드가 이걸 써도 돼'라고 말하는 명시적 부여야. 그 분리가 플러그인이 네 바이너리에 있되 네가 opt-in 하기 전엔 웹뷰에서 못 닿게 해 — 구조에 의한 보안, 세 편집으로 지불.

Code

표면 1: 의존성·toml

# 표면 1 — Cargo.toml: Rust 크레이트.
[dependencies]
tauri-plugin-store = "2"

표면 2: 빌더 등록·rust

// 표면 2 — lib.rs: 빌더에 등록.
tauri::Builder::default()
    .plugin(tauri_plugin_store::Builder::new().build())
    // ...

표면 3: capability permission·json

// 표면 3 — capabilities/default.json: permission 부여.
{
  "permissions": [
    "core:default",
    "store:default"
  ]
}

Exercise

store 플러그인을 손으로 앱에 더해, 세 표면을 의도적으로 다 건드려: Cargo 의존성, 빌더 줄, capability permission(거기에 JS 패키지). 그다음 값을 저장하고 영속하는지 확인해. 보너스: capability 줄만 주석 처리하고 프론트엔드 호출이 실패하는 걸 봐 — 그 조용한 실패가 규칙이 존재하는 이유 전부야.

Hint

표면: Cargo.toml에 tauri-plugin-store, lib.rs에 .plugin(tauri_plugin_store::Builder::new().build()), capabilities에 "store:default", npm으로 @tauri-apps/plugin-store. capability 제거하면 나머지는 멀쩡해 보이는데 permission 에러가 나.