Add native support for desktop and android (Tauri) #4379
Conversation
✅ Deploy Preview for origin-betaflight-app ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
I haven't tested it, but two questions or confirmations:
I'm right? |
|
For now this is for evaluation purpose |
haslinghuis
force-pushed
the
tauri
branch
2 times, most recently
from
4ba0507 to
eff5f85
Compare
|
I'm new to PWA , I want use tauri to communite with mavsdk , I want to base this project, I have no idea with this PWA , I don't know how to add tauri callback in this PWA,Can you give me some ideas. |
|
WalkthroughAdds Tauri desktop/mobile integration and native Tauri serial transport, updates frontend runtime detection and serial wiring, introduces Android/Tauri npm scripts and dependencies, adds Docker and Android build tooling and docs, adjusts Vite/ESLint/.gitignore, and restructures CI/release GitHub Actions. Changes
Sequence Diagram(s)sequenceDiagram
participant App as Betaflight App (UI)
participant PortHandler as PortHandler
participant Serial as Serial Manager
participant Protocol as Protocol (TauriSerial / WebSerial)
participant Backend as Backend (Tauri / Browser)
App->>PortHandler: initialize()
PortHandler->>PortHandler: detect runtime (isTauri)
PortHandler->>Serial: selectProtocol()
alt Tauri runtime
Serial->>Serial: async load TauriSerial
Serial->>Protocol: instantiate TauriSerial
Protocol->>Backend: queryAvailablePorts()
else Web runtime
Serial->>Protocol: use WebSerial
Protocol->>Backend: requestPort()/enumerate()
end
Serial->>Serial: setup event forwarding
Protocol-->>Serial: emit addedDevice/removedDevice/connect/receive
Serial-->>App: forward device/events (include protocolType)
App->>PortHandler: connect(port)
PortHandler->>Serial: connect(port)
Serial->>Protocol: connect(path, options)
Protocol->>Backend: openPort(path, baudRate)
Protocol->>Protocol: startReadLoop()
loop Data reception
Protocol->>Backend: poll/read data
Backend-->>Protocol: data (Uint8Array)
Protocol->>Serial: emit receive(data)
Serial-->>App: forward data
end
App->>PortHandler: send(data)
PortHandler->>Serial: send(data)
Serial->>Protocol: write(data)
Protocol->>Backend: writePort(data)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Areas needing extra attention:
Possibly related issues
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src-tauri/src/main.rs (1)
6-11: Consider improving error handling for production use.The main function structure is correct and follows Tauri best practices. However, using
.expect()will cause the application to panic on startup errors.For production use, consider implementing more graceful error handling:
fn main() { - tauri::Builder::default() - .plugin(tauri_plugin_shell::init()) - .run(tauri::generate_context!()) - .expect("error while running tauri application"); + if let Err(e) = tauri::Builder::default() + .plugin(tauri_plugin_shell::init()) + .run(tauri::generate_context!()) { + eprintln!("Failed to start application: {}", e); + std::process::exit(1); + } }Given this is experimental/evaluation code, the current approach is acceptable for now.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
src-tauri/Cargo.lockis excluded by!**/*.locksrc-tauri/icons/bf_icon_128.pngis excluded by!**/*.pngyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (8)
.gitignore(1 hunks)package.json(2 hunks)src-tauri/Cargo.toml(1 hunks)src-tauri/build.rs(1 hunks)src-tauri/src/main.rs(1 hunks)src-tauri/tauri.conf.json(1 hunks)src/js/utils/checkBrowserCompatibility.js(1 hunks)vite.config.js(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
src-tauri/src/main.rs (1)
src-tauri/build.rs (1)
main(1-3)
src-tauri/build.rs (1)
src-tauri/src/main.rs (1)
main(6-11)
🔇 Additional comments (16)
.gitignore (1)
45-47: LGTM! Standard Tauri ignore patterns added.The added entries correctly exclude Tauri build artifacts:
src-tauri/target/for Rust/Cargo compilation artifactssrc-tauri/gen/for Tauri-generated codeThese are essential for keeping build outputs out of version control.
src-tauri/build.rs (1)
1-3: LGTM! Standard minimal Tauri build script.This is the correct minimal implementation for a Tauri build script. The
tauri_build::build()call handles all necessary Tauri-specific build steps during compilation.vite.config.js (2)
59-60: LGTM! Build configuration aligned with Tauri requirements.The explicit
outDir: "dist"andemptyOutDir: truesettings ensure that the frontend build outputs are correctly placed and cleaned for Tauri consumption.
120-120: LGTM! Convenient alias for source directory.The
"@": resolve(__dirname, "src")alias provides a clean way to reference the source directory in imports, which is a common pattern in Vue.js projects.src-tauri/src/main.rs (1)
1-4: LGTM! Correct Windows subsystem configuration.The conditional compilation attribute properly suppresses the console window on Windows in release builds, which is appropriate for a desktop GUI application.
src/js/utils/checkBrowserCompatibility.js (2)
63-65: LGTM! Standard Tauri detection implementation.The function correctly uses the
__TAURI_INTERNALS__global variable to detect when running in a Tauri environment, which is the recommended approach according to Tauri documentation.
73-73: Good integration with existing platform detection.Correctly treats Tauri as a native platform alongside Capacitor, which makes sense since both provide native desktop/mobile app capabilities that don't require web browser APIs like WebSerial or WebUSB.
src-tauri/tauri.conf.json (3)
25-28:❓ Verification inconclusive
Bundle targets are Linux-focused - confirm platform strategy.
The bundle configuration only targets Linux packages (deb, appimage). Given that the PR mentions this is for evaluation purposes, confirm whether Windows and macOS targets will be added later or if Linux-only distribution is intentional.
🌐 Web query:
What are the recommended bundle targets for Tauri v2 cross-platform desktop applications?💡 Result:
In Tauri v2, when configuring your cross-platform desktop application, you can specify the bundle targets in the
tauri.conf.jsonconfiguration file under thebundlesection. Thetargetsproperty defines the formats in which your application will be bundled. By default, this is set to"all", which includes all available targets. You can customize this to include specific targets as needed.The available bundle targets are:
Windows:
"nsis": NSIS installer (.exe)"msi": Microsoft Installer (.msi)"app": Windows application bundle (.app)"dmg": Apple Disk Image (.dmg)macOS:
"app": macOS application bundle (.app)"dmg": Apple Disk Image (.dmg)Linux:
"deb": Debian package (.deb)"rpm": RPM package (.rpm)"appimage": AppImage bundle (.appimage)Cross-Platform:
"all": Bundles all available targetsTo specify the bundle targets in your
tauri.conf.jsonfile, you can set thetargetsproperty under thebundlesection. For example, to bundle your application for Windows and macOS, you would configure it as follows:{ "bundle": { "targets": ["nsis", "app", "dmg"] } }This configuration will generate installers for Windows (
.exe), and application bundles for macOS (.appand.dmg). For a comprehensive list of all available bundle targets and their configurations, refer to the Tauri documentation. (tauri.app)Citations:
Clarify cross-platform bundle targets
Currently in
src-tauri/tauri.conf.json(around lines 25–28) your bundle targets are set to:"bundle": { "active": true, "targets": ["deb", "appimage"], "icon": ["icons/bf_icon_128.png"] }– those are Linux-only formats. Tauri v2 also supports Windows (
"nsis","msi","app","dmg") and macOS ("app","dmg") bundles, or a single"all"target to cover everything.Please confirm whether you intend to ship Linux-only (for evaluation) or if you’ll add Windows/macOS targets (or switch to
"all") before release.
5-9:✅ Verification successful
Verify build commands consistency.
The build commands reference
yarn devandyarn buildscripts. Ensure these correspond to the scripts defined in package.json and that the development server runs on the configured port (8000).
🏁 Script executed:
#!/bin/bash # Verify that the referenced yarn scripts exist in package.json echo "Checking for yarn scripts referenced in tauri.conf.json..." jq -r '.scripts | keys[]' package.json | grep -E "^(dev|build)$" || echo "Missing required scripts" # Check if dev script uses port 8000 echo "Checking dev script configuration..." jq -r '.scripts.dev' package.jsonLength of output: 325
🏁 Script executed:
#!/bin/bash # Locate any Vite config files in the repo echo "Locating vite config files..." vite_configs=$(fd -t f -H "vite.config.*") if [ -z "$vite_configs" ]; then echo "No vite.config.* files found." else for cfg in $vite_configs; do echo "Inspecting $cfg for server port settings:" grep -R "server" -n "$cfg" -A3 || echo "No 'server' block in $cfg" grep -R "port" -n "$cfg" || echo "No explicit port setting in $cfg" done fiLength of output: 1222
Build commands and devUrl verified
- Both
devandbuildscripts exist in package.json.- The Vite dev server is explicitly configured with
which matchesserver: { port: 8000, strictPort: true, }"devUrl": "http://localhost:8000"in tauri.conf.json.- The frontend build output defaults to
dist, so"frontendDist": "../dist"is correct.No changes required.
30-34:❓ Verification inconclusive
Shell plugin enabled - verify security implications.
The shell plugin with
open: trueallows the application to execute system commands and open files/URLs. Ensure this is necessary for the application's functionality and that proper input validation is implemented wherever this plugin is used.
🏁 Script executed:
#!/bin/bash # Search for usage of Tauri shell plugin in the codebase echo "Searching for shell plugin usage..." rg -A 3 -B 3 "shell|invoke.*shell|@tauri-apps.*shell" --type jsLength of output: 146
This will confirm whether the shell plugin is actually referenced in your Rust code.
🏁 Script executed:
#!/bin/bash echo "Searching for shell plugin usage in Rust code..." # Look for direct imports of the shell plugin rg -n "use .*shell" --type rs # Look for any references to the plugin namespace rg -n "tauri_plugin_shell" --type rs # Look for any invocation or initialization calls rg -A3 -B3 "shell::" --type rsLength of output: 287
🏁 Script executed:
#!/bin/bash echo "Locating Cargo.toml files..." find . -maxdepth 4 -type f -name Cargo.toml echo echo "Checking for tauri-plugin-shell in Cargo.toml dependencies..." rg -n "tauri-plugin-shell" -g "*.toml" echo echo "Searching Rust source for plugin initialization or references..." rg -n "tauri_plugin_shell" -g "*.rs" rg -n "shell::init" -g "*.rs" rg -n "plugin(" -g "*.rs" | grep shell || true echo echo "Searching front-end code for shell plugin invocations..." rg -n "plugin:shell" -g "*.js" -g "*.ts" -g "*.tsx"Length of output: 1014
Verify Shell Plugin Necessity and Usage
The Tauri Shell plugin is enabled in your configuration and initialized in the Rust backend, but we didn’t find any front-end invocations. Please confirm whether you actually need this plugin, and if so, ensure every call is properly validated to avoid command injection or unintended file/URL access.
• src-tauri/tauri.conf.json (lines 30–34):
"plugins": { "shell": { "open": true } }
• src-tauri/Cargo.toml (line 15):tauri-plugin-shell = "2.0.0"
• src-tauri/src/main.rs (line 8):.plugin(tauri_plugin_shell::init())If the shell plugin isn’t used, remove it to reduce your attack surface. Otherwise, audit all places where you call into the shell API and enforce strict input validation.
package.json (2)
26-27: LGTM! Standard Tauri script integration.The script names follow Tauri conventions and integrate well with the existing build workflow. These scripts correspond to the build commands configured in
tauri.conf.json.
25-25: Minor modification to prepare script looks correct.The husky install preparation remains intact, which is good for maintaining git hooks functionality.
src-tauri/Cargo.toml (4)
1-8: Excellent version consistency across the project.The package metadata properly matches the version (11.0.0) and project details from
package.jsonandtauri.conf.json, ensuring consistency across the Tauri integration.
13-17: Standard and appropriate Tauri dependencies.The dependency selection is correct for a basic Tauri v2 application:
- Core Tauri framework
- Shell plugin for system interactions
- Serde for JSON serialization (standard for Tauri apps)
19-21: Custom protocol feature is a good security practice.Enabling the
custom-protocolfeature is recommended for production Tauri applications as it provides better security than the default localhost-based approach during development.
10-11:✅ Verification successful
Verify Tauri build dependency version compatibility.
Let's ensure the tauri-build version is compatible with the runtime tauri dependency version (both should be from the same major.minor release).
🌐 Web query:
Are tauri-build 2.0.6 and tauri 2.0.6 compatible versions for Tauri v2 applications?💡 Result:
Yes, tauri-build 2.0.6 and tauri 2.0.6 are compatible versions for Tauri v2 applications. The Tauri framework follows semantic versioning principles where the major version number is incremented for breaking changes, and minor or patch updates are backward compatible within the same major version. This means you should always be able to safely upgrade to the latest minor or patch versions without compatibility issues between related crates like tauri and tauri-build[2][8].
Specifically, at version 2.0.6, tauri and tauri-build are aligned as part of the Tauri 2.x stable release series, ensuring compatibility for building and running Tauri v2 applications[1][6]. It is recommended to keep the versions of the Tauri core crates (like tauri and tauri-build) in sync, generally using the exact same version number, to avoid any subtle incompatibilities[8].
Therefore, using tauri 2.0.6 together with tauri-build 2.0.6 is the correct approach for Tauri v2 apps.
Citations:
- 1: https://v2.tauri.app/blog/tauri-20/
- 2: https://v2.tauri.app/develop/configuration-files/
- 3: https://github.com/tauri-apps/tauri
- 4: tauri-apps/tauri#8813
- 5: https://v2.tauri.app/distribute/windows-installer/
- 6: https://tauri.app/release/@tauri-apps/cli/v2.0.0-alpha.6/
- 7: tauri-apps/tauri#9039
- 8: https://v2.tauri.app/develop/updating-dependencies/
- 9: tauri-apps/tauri#8563
- 10: https://v2.tauri.app/plugin/updater/
Tauri build dependency version compatibility confirmed
The tauri-build entry in
src-tauri/Cargo.tomlis already at version 2.0.6, matching the runtimetauri = "2.0.6"release. Since Tauri follows semantic versioning within the 2.x series, these versions are fully compatible—no changes needed.
haslinghuis
force-pushed
the
tauri
branch
2 times, most recently
from
2da39ae to
7455b58
Compare
|
haslinghuis
force-pushed
the
tauri
branch
2 times, most recently
from
d0d9251 to
eb89b5d
Compare
…tifact path (src/dist/) to fix missing assets
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src-tauri/tauri.conf.json (1)
30-31: Icon bundle configuration is incomplete for macOS and Windows.The
iconarray (line 31) only includes the PNG for Linux. Tauri v2 bundle targets declared on line 30 includedmg(macOS) andnsis(Windows), which require:
- macOS (dmg):
bf_icon.icns- Windows (nsis):
bf_icon.icoWithout these, the build will fail or produce warnings on those platforms. Run
yarn tauri iconto generate missing formats from the existing PNG, then update line 31 to include all generated files.- "icon": ["icons/bf_icon_128.png"] + "icon": ["icons/bf_icon_128.png", "icons/bf_icon.icns", "icons/bf_icon.ico"](Ensure the generated
.icnsand.icofiles exist insrc-tauri/icons/first.)
🧹 Nitpick comments (2)
.github/workflows/ci.yml (1)
78-87: Add Rust target caching to avoid redundant builds.The
tauri-linux-previewjob rebuilds the entire Rust target directory on every run, which can be slow. Add a Rust cache step usingswatinem/rust-cache@v2after the toolchain installation to significantly reduce build times.- name: Install Rust uses: dtolnay/rust-toolchain@stable + - name: Cache Rust + uses: swatinem/rust-cache@v2 + with: + workingDirectory: src-tauri + - name: Build web assets (Vite)src-tauri/tauri.conf.json (1)
34-36: Consider restricting shellopento trusted URL patterns.Line 35 sets
"open": true, which broadly permits opening any URL. For better security posture, restrict this to a regex allowlist (e.g., onlyhttpsURLs or a specific domain allowlist) to reduce attack surface."plugins": { "shell": { - "open": true + "open": "^https://\\w.+" } }(Adjust the regex to match your application's URL scheme and security requirements.)
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/ci.yml(1 hunks)src-tauri/tauri.conf.json(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Tauri Linux preview (deb/appimage)
🔇 Additional comments (2)
.github/workflows/ci.yml (2)
78-79: ✓ Critical issue resolved: Rust toolchain now properly installed.The explicit Rust toolchain setup is now present using
dtolnay/rust-toolchain@stable, which addresses the critical issue flagged in the previous review. The placement after Linux dependencies and before the Tauri build step is correct.
85-87: No issues found—script is correctly defined.The verification confirms that
tauri:buildis properly defined in package.json as"tauri:build": "tauri build", matching the reference in the CI workflow at line 87.
… libudev-sys and OpenSSL dependencies
|
First linux debian artifact: https://github.com/betaflight/betaflight-configurator/actions/runs/18810125440/artifacts/4372439098 |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
.github/workflows/ci.yml (3)
81-101: Consider adding Rust cache to speed up Cargo builds.The
tauri-linux-previewjob installs Rust but lacks caching for the Cargo build artifacts. Subsequent runs will recompile dependencies, making builds slower. Add a Rust cache step after the toolchain setup to improve CI performance on repeated builds.- name: Install Rust uses: dtolnay/rust-toolchain@stable + - name: Cache Rust build artifacts + uses: swatinem/rust-cache@v2 + with: + workspaces: src-tauri - name: Build web assets (Vite)
48-48: Align artifact retention days across jobs.Artifact retention varies:
web-dist(14 days),linux-installers(14 days), andlinux-bundle-raw(7 days). Consider aligning retention policies for consistency unless the shorter retention for raw bundles is intentional (e.g., fallback-only, lower priority).Also applies to: 111-111, 120-120
142-156: Consider alternative to Docker image tar export for CI artifacts.Exporting Docker images to tar and uploading them as artifacts can result in very large files (hundreds of MB–GB depending on the image). If the goal is to enable downstream consumption of the built image, consider using a container registry (GitHub Container Registry, DockerHub, etc.) instead, which avoids large artifact uploads and integrates better with container ecosystems.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/ci.yml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Tauri Linux preview (deb/appimage)
🔇 Additional comments (1)
.github/workflows/ci.yml (1)
50-54: Clarify the intent of PR-only gating for Tauri builds.The
tauri-linux-previewjob is conditioned to run only onpull_requestevents (line 54), but the workflow also triggers onpushto thetauribranch (line 7). This means Tauri builds won't execute on direct pushes to the branch — only on PRs. Verify this is intentional (e.g., preview-only during development) or consider adjusting the condition.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/workflows/ci.yml (2)
81-93: Add Rust build cache to optimize rebuild times.The Rust toolchain is correctly installed (line 81-82), but the job lacks a Rust build cache. Since Tauri builds can be time-consuming, caching the Cargo target directory will significantly speed up subsequent runs. This is a recommended optimization for CI efficiency.
Add a Rust cache step after the Rust toolchain installation:
- name: Install Rust uses: dtolnay/rust-toolchain@stable + - name: Cache Rust (Cargo) + uses: swatinem/rust-cache@v2 + with: + workspaces: src-tauri + - name: Build web assets (Vite)This will cache Cargo's target directory for the
src-tauriworkspace, significantly reducing build times on repeated runs.
87-102: Narrow the AppImage artifact glob pattern to prevent unintended matches.The tauri-action@v0 configuration (lines 87-102) is correct—
tauriScript: yarn tauriandincludeUpdaterJson: falseare valid, supported options. Tauri produces deb files atsrc-tauri/target/release/bundle/deb/and AppImage files atsrc-tauri/target/release/bundle/appimage/.The glob pattern
src-tauri/target/release/bundle/**/*.debcorrectly matches deb output. However,**/*.AppImageis overly broad and could match AppImage files anywhere in the repository. Change it tosrc-tauri/target/release/bundle/**/*.AppImage(or the more specificsrc-tauri/target/release/bundle/appimage/*.AppImage) for consistency and to avoid unintended matches.The debug inspection at lines 95–101 is helpful for verification.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/artifact-links.yml(1 hunks).github/workflows/ci.yml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Tauri Linux preview (deb/appimage)
🔇 Additional comments (5)
.github/workflows/artifact-links.yml (1)
1-20: Trigger alignment is correct.Aligning the artifact-links workflow to trigger on CI workflow completion (rather than direct PR events) ensures artifact links are posted after all conditional build jobs finish, including the new tauri-linux-preview and docker-build steps.
.github/workflows/ci.yml (4)
3-14: Workflow triggers and inputs are well-configured.The setup correctly routes pull requests and push events on the tauri branch, and the optional workflow_call input with a safe default (false) enables reusable workflow patterns for Docker builds without inadvertently triggering extra jobs.
17-48: Node CI job is well-structured and follows best practices.The streamlined job structure (checkout → setup → install → lint → test → build → upload) is clearer than a multi-platform matrix. Frozen lockfile at line 31 prevents dependency drift, and the 14-day artifact retention balances storage costs with debugging needs.
68-79: Linux dependencies are comprehensive and well-chosen.The dependency list (pkg-config, libgtk-3-dev, libwebkit2gtk-4.1-dev, libayatana-appindicator3-dev, librsvg2-dev, libudev-dev, libssl-dev, patchelf) covers the core requirements for Tauri on Linux, including additions like libudev-dev and libssl-dev for serial/USB and SSL support respectively.
113-147: Docker build job is well-designed with safe conditionals.The job correctly gates Docker builds to reusable workflow calls with the
run_docker_buildflag (line 118), and the Dockerfile presence check (lines 127-131) with conditional step execution (lines 134, 138, 143) ensures graceful handling whether or not a Dockerfile exists. Artifact retention of 7 days is appropriate for Docker images.
…lity and formatting
|
|
Preview URL: https://pr4379.betaflight-app-preview.pages.dev |
haslinghuis
changed the title
4 participants
References
Todo
Follow up
Not sure Docker is a good solution as we need to avoid sandboxing
Requirements
Docker
Tauri Integration:
package.json: Added new scripts for Tauri development and build, and included Tauri dependencies (@tauri-apps/apiand@tauri-apps/cli). [1] [2]src-tauri/Cargo.toml: Created a new Cargo configuration file for the Tauri application.src-tauri/build.rs: Added a build script for Tauri.src-tauri/src/main.rs: Set up the main entry point for the Tauri application.src-tauri/tauri.conf.json: Created a Tauri configuration file with application settings and build commands.Build Configuration:
vite.config.js: Updated the build output directory and added an alias for thesrcdirectory. [1] [2]Summary by CodeRabbit
New Features
Documentation
Chores
Build / Config