Sharing Plugins Between Projects

A plugin that lives in a single project stops being a plugin and becomes just another module. The real power of the plugin system is that you build a feature once—a file system tool, a database layer, a custom authentication flow—and use it in every Tauri app you maintain, or even share it with the community. This guide walks through packaging a Tauri v2 plugin so other projects can depend on it, from the first cargo new to publishing on registries and wiring it into a consumer app with a React + Vite frontend. The Plugin Structure page is the layout this packaging assumes.

What Makes a Plugin Shareable?

A Tauri plugin is considered reusable when it exists as a separate Rust crate and an accompanying NPM package, completely independent of any application project. The crate exposes commands through Tauri's plugin infrastructure; the NPM package wraps those commands in a typed JavaScript API that the frontend can call directly.

Inline plugins—where you define a plugin's logic inside the same crate as your application, often by calling Builder::new in lib.rs—are convenient for organizing internal code. They are not a sharing mechanism. In Tauri v2, inline plugins require modifying build.rs to include the permission manifest manually, and they cannot be imported by another project without copying source files, which quickly breaks when permissions and APIs diverge.

A shareable plugin project therefore contains two distinct packages: a Cargo crate (the Rust side) and an NPM package (the JavaScript bindings). Both must be published or linked so that a consumer app can pull them in like any other dependency.

Creating a Reusable Plugin

The steps below build a small plugin called greeter that exposes a single command: greet(name: String) -> String. You can replace the logic with your own feature once you understand the flow.

npx @tauri-apps/cli plugin new greeter

tauri-plugin-greeter/
├── src/
│   ├── commands.rs        # Where your command implementations live
│   ├── desktop.rs         # Desktop-specific logic
│   ├── error.rs           # Custom error type
│   ├── lib.rs             # Plugin entry point
│   ├── mobile.rs          # Mobile-specific logic
│   └── models.rs          # Shared data structures
├── permissions/           # Permission definitions for the plugin
├── guest-js/              # TypeScript source for the JS bindings
├── dist-js/               # Compiled JS output (created after build)
├── Cargo.toml
└── package.json

use tauri::command;
#[command]
pub fn greet(name: String) -> String {
    format!("Hello, {}! From the greeter plugin.", name)
}

use tauri::{
    plugin::{Builder, TauriPlugin},
    Runtime,
};
mod commands;
mod error;
mod mobile;
mod desktop;
pub use error::{Error, Result};
/// Initializes the greeter plugin.
pub fn init<R: Runtime>() -> TauriPlugin<R> {
    Builder::new("greeter")
        .invoke_handler(tauri::generate_handler![commands::greet])
        .build()
}

import { invoke } from '@tauri-apps/api/core';
/**
 * Sends a name to the Rust backend and gets a greeting back.
 * @param name - The name to greet.
 * @returns A greeting string.
 */
export async function greet(name: string): Promise<string> {
    return await invoke('plugin:greeter|greet', { name });
}

{
    "name": "@my-scope/tauri-plugin-greeter",
    "version": "0.1.0",
    "main": "dist-js/index.js",
    "types": "dist-js/index.d.ts",
    "scripts": {
        "build": "tsc"
    },
    "dependencies": {
        "@tauri-apps/api": "^2.0.0"
    },
    "devDependencies": {
        "typescript": "^5.0.0"
    }
}

{
    "compilerOptions": {
        "target": "ES2020",
        "module": "ESNext",
        "moduleResolution": "bundler",
        "strict": true,
        "outDir": "../dist-js",
        "declaration": true,
        "declarationMap": true,
        "sourceMap": true
    },
    "include": ["./**/*.ts"]
}

npm run build

[default]
description = "Default permissions for the greeter plugin"
[[permission]]
identifier = "greeter:default"
description = "Allows the greet command"
commands.allow = ["greet"]

fn main() {
    tauri_build::build()
}

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_greeter::init())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

{
    "identifier": "default-capability",
    "windows": ["main"],
    "permissions": [
        "core:default",
        "greeter:default"
    ]
}

import { greet } from '../../../guest-js/index.ts';
greet('Tauri').then(console.log);

Sharing the Plugin Locally

Before publishing to a public registry, you often share plugins between projects on your own machine—for instance, when building a suite of internal tools that share a common data-access plugin.

Rust side: In the consumer app's Cargo.toml, point the dependency to the local path.

[dependencies]
tauri-plugin-greeter = { path = "../../tauri-plugin-greeter" }

JavaScript side: In the consumer app's package.json, use a file: protocol to reference the plugin's root directory.

"dependencies": {
    "@my-scope/tauri-plugin-greeter": "file:../tauri-plugin-greeter"
}

Run npm install to create the symlink. Cargo and npm will now resolve the plugin from your local filesystem. Any change you make to the plugin is reflected immediately in the consumer app after a rebuild—no publish step required during development.

Publishing to Registries

When the plugin is stable and you want to share it publicly or across team machines without path dependencies, publish both the crate and the NPM package.

Cargo crate (crates.io):

1. Make sure Cargo.toml includes a description, license, and repository field. These are required for publishing.
2. Log in with cargo login.
3. Run cargo publish from the plugin's root.

NPM package (npm registry):

1. Update package.json with a description, license, and repository if missing.
2. Build the JavaScript bindings: npm run build.
3. Log in with npm login.
4. Run npm publish --access public (the --access public is required for scoped packages the first time).

Version both the crate and the NPM package together. Semantic versioning helps consumers understand the impact of updates. A breaking change in the Rust API should be accompanied by a major version bump in both packages, along with clear migration notes.

Using a Shared Plugin in a Tauri App

Assume the plugin is now available—either from a registry or via a local path. The consumer app is a standard Tauri v2 project with React + Vite as the frontend. Here is how to integrate the greeter plugin.

1. Add the Rust dependency and register the plugin.

In src-tauri/Cargo.toml, add the dependency (with the correct version or path):

[dependencies]
tauri-plugin-greeter = "0.1.0"

Register the plugin in src-tauri/src/lib.rs:

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_greeter::init())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

2. Install the JavaScript bindings.

npm install @my-scope/tauri-plugin-greeter

3. Add the plugin's permissions to a capability file.

Every command in Tauri v2 must be explicitly allowed. The plugin ships a permission set greeter:default. Add it to the capability assigned to the windows that need it.

{
    "identifier": "main-capability",
    "description": "Capability for the main window",
    "windows": ["main"],
    "permissions": [
        "core:default",
        "greeter:default"
    ]
}

4. Call the command from the React frontend.

import { useState } from 'react';
import { greet } from '@my-scope/tauri-plugin-greeter';
function App() {
    const [message, setMessage] = useState('');
    const handleGreet = async () => {
        const msg = await greet('World');
        setMessage(msg);
    };
    return (
        <div>
            <button onClick={handleGreet}>Greet</button>
            <p>{message}</p>
        </div>
    );
}
export default App;

When the button is clicked, the string Hello, World! From the greeter plugin. appears on screen. No extra configuration is needed beyond the steps above.

Designing Plugin Configuration

Many plugins need user‑specific settings—database URLs, timeouts, feature flags. Tauri allows plugins to read configuration from the plugins section of tauri.conf.json.

In the plugin's src/lib.rs, define a configuration struct and read it during setup:

use serde::Deserialize;
use tauri::{
    plugin::{Builder, TauriPlugin},
    Runtime,
};
#[derive(Deserialize)]
pub struct Config {
    pub prefix: Option<String>,
}
pub fn init<R: Runtime>() -> TauriPlugin<R, Config> {
    Builder::<R, Config>::new("greeter")
        .setup(|app, api| {
            let prefix = api.config().prefix.clone().unwrap_or_else(|| "Hello".into());
            // Store the prefix in managed state so commands can access it
            app.manage(prefix);
            Ok(())
        })
        .invoke_handler(tauri::generate_handler![commands::greet])
        .build()
}

A consumer app can then provide the configuration:

{
    "plugins": {
        "greeter": {
            "prefix": "Hi"
        }
    }
}

The command would then retrieve the prefix from the managed state instead of hardcoding it. This pattern keeps plugins generic while allowing each project to customize behavior.

Common Pitfalls

Best Practices

• Ship minimal default permissions. Only allow commands that are safe for general use. Commands that access the filesystem or network should be placed in separate permission sets that the consumer opts into explicitly.
• Document the configuration schema. Include a commented example in the plugin's README so that developers know what keys are available and what they do.
• Version with intent. Bump the major version when you rename a command, change its signature, or alter the required permissions. Consumers rely on semantic versioning to decide when to upgrade.
• Test across platforms early. A plugin that works on macOS may fail on Windows due to path separators or missing APIs. Use CI to build and test on all target platforms before publishing.
• Keep the JavaScript API thin. The frontend binding should only serialize arguments and call invoke. Complex logic belongs in Rust, where it is faster and more secure.

Summary

A shareable plugin is the foundation for building a Tauri ecosystem. Once you are comfortable distributing plugins, you can share them across your organization. If you need mobile support, the Mobile Plugin Development guide extends the pattern shown here to Kotlin and Swift.