denoland/deno · error

invalid --output: dylib path has no file stem

Error message

invalid --output: dylib path has no file stem: {}

What it means

Third check in dylib_parts(): file_stem() extracts the app name by stripping the dylib extension. In std, file_stem() returns None only when file_name() is None, and file_name was already validated on the line above — so this branch is a defensive near-unreachable guard keeping the function total (no unwrap panics) rather than a realistic failure mode.

Solutions

  1. Re-run with a normal, fully-named dylib path (./dist/app.dylib) — the error should be unreachable.
  2. If it reproduces, capture the exact --output string and file a deno bug, since the guard is not expected to fire.
Defensive patterns

Strategy: validation

Prevention

When it happens

Trigger: Requires dylib_path.file_stem() to be None while file_name() succeeded, which Rust's Path semantics do not produce; it exists so future refactors of the checks cannot reintroduce a panic.

Common situations: None realistically; hit it only via a bug or a future std behavior change. Any occurrence should be reported as a deno issue with the exact --output value.

Related errors


AI-assisted analysis of denoland/deno@f7822238ca (2026-08-20). Data as JSON: /api/errors/db08ce4023aebd9f. Report an issue: GitHub.

Appendix: source

Thrown at cli/tools/desktop.rs:3019

}

fn dylib_parts(dylib_path: &Path) -> Result<DylibParts<'_>, AnyError> {
  let parent = dylib_path.parent().ok_or_else(|| {
    deno_core::anyhow::anyhow!(
      "invalid --output: dylib path has no parent dir: {}",
      dylib_path.display()
    )
  })?;
  let file_name = dylib_path.file_name().ok_or_else(|| {
    deno_core::anyhow::anyhow!(
      "invalid --output: dylib path has no file name: {}",
      dylib_path.display()
    )
  })?;
  let app_name = dylib_path
    .file_stem()
    .ok_or_else(|| {
      deno_core::anyhow::anyhow!(
        "invalid --output: dylib path has no file stem: {}",
        dylib_path.display()
      )
    })?
    .to_string_lossy()
    .into_owned();
  Ok(DylibParts {
    parent,
    file_name,
    app_name,
  })
}

/// The runtime library filename the Linux launcher resolves for an app named
/// `app_name`.
///
/// laufey's `LaufeyFindColocatedRuntime` chops everything after the last dot of
/// the executable's file name — an extension a Linux launcher doesn't have —

View on GitHub (pinned to f7822238ca)