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

"플러그인은 세 군데에 다 있기 전엔 설치된 게 아냐. 그리고 셋 중 둘은 소리 없이 실패해."

세 표면, 매번

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가 정확히 이걸 교훈으로 적어뒀어 — 플러그인 하나를 빼는 일은 Cargo 의존성이랑 lib.rs 빌더랑 거기에 capabilities 파일까지 발맞춰 고치는 일이었거든. 넣을 때도 뺄 때도 똑같이 세 표면 작업이야.

왜 이렇게 설계했나

절차가 번거롭게 느껴질 수 있는데, 표면마다 기본 거부 모델에서 맡은 역할이 있어. Cargo 의존성이 코드를 가져오고, 빌더가 코어에서 그걸 켜고, capability가 '그래, 프론트엔드가 이걸 써도 돼'라고 명시적으로 허락해. 그렇게 갈라놨기 때문에 플러그인이 네 바이너리 안에 들어 있으면서도 네가 켜주기 전엔 웹뷰에서 닿을 수 없는 거야 — 구조로 만든 보안이고, 값은 편집 세 번으로 치르는 거지.

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 에러가 나.