Skip to content

fix(cli): avoid unwrap panic when resolving npm_execpath on Windows - #14476

Closed
sakina1303 wants to merge 1 commit into
tauri-apps:devfrom
sakina1303:bunfix
Closed

fix(cli): avoid unwrap panic when resolving npm_execpath on Windows#14476
sakina1303 wants to merge 1 commit into
tauri-apps:devfrom
sakina1303:bunfix

Conversation

@sakina1303

Copy link
Copy Markdown

This PR fixes a panic that occurred during tauri android init when npm_execpath pointed to a path where file_stem() returned None—a situation that happens on some Windows setups and when using Bun.

Previously, the code called:

file_stem().unwrap().to_os_string()

If file_stem() returned None, the CLI crashed with an unwrap() panic.

What this PR changes-

This replaces the unsafe unwrap() with a safe fallback chain:

  1. file_stem()
  2. Or file_name()
  3. Or the original npm_execpath
    This ensures that the CLI never panics due to unexpected or non-standard npm/bun paths.

Why this is correct-

  • Handles Windows-specific cases where file_stem() legitimately returns None.
  • Makes the manager detection code fully panic-safe across all platforms.
  • Does not change higher-level behavior or command semantics.
  • Fixes the root cause of the crash without introducing breaking changes.

Verification-

  • Rebuilt tauri-cli
  • Symlinked the binary to node and set npm_execpath="/" to simulate the failing scenario
  • Confirmed the CLI no longer panics and proceeds normally

Fixes #14472

@sakina1303

Copy link
Copy Markdown
Author

@FabianLars Hi! Just wanted to check if this approach looks good to you, or if you’d like any adjustments.

@FabianLars

Copy link
Copy Markdown
Member

first of all i'd like us to investigate the user's issue a bit since this is not a common occurrence (we have many bun users). Depending on the root cause your PR may not even fix it for them.

Secondly, if we do need special handling for bun i'd prefer if it could look closer to the pnpm handling or the deno check rather than the extra stem check upfront.

@sftse

sftse commented Dec 3, 2025

Copy link
Copy Markdown
Contributor
  1. On all platforms it holds that path.file_name().is_some() == path.file_stem().is_some() so at least one of the introduced fallbacks is useless.
  2. This may or may not have to do with Windows, where there are more ways of expressing drive prefixes/root directories, all of which return p.file_name().is_none():

".."
"../"
"."
"./"
""
"/"
"..\"
".\"
"C:\"
"\\?\c:\"
"\\server\share"
"\\.\BrainInterface"
"\\?\UNC\server\share"
"\\?\pictures"

  1. There are legitimate ways non-windows platforms can return None for the file stem.

Based on the nonsensical description this is likely AI-generated.

@FabianLars FabianLars closed this Jan 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug] bun tauri android init fails on Windows

3 participants