denoland/deno · error

app name {app_name:?} resolves its {kind} to {name}, which i

Error message

app name {app_name:?} resolves its {kind} to {name}, which is already part of the app. Choose a different --output name.

What it means

This error is thrown by `reject_backend_file_collision` in cli/tools/desktop.rs when a backend file that the app builder needs to write (e.g. a launcher binary or runtime dylib for a given `--output` name) already exists at the target path. Since that existing file is already 'part of the app', overwriting it would corrupt the bundle, so the tool refuses and asks for a different --output name. It is a deliberate safety guard against name collisions inside the generated desktop app layout.

Source

Thrown at cli/tools/desktop.rs:3140

/// Refuse an app-derived file name that lands on a file the backend shipped.
///
/// The app dir starts life as a copy of the LAUFEY backend directory, so it
/// already holds the backend's own files — `libcef.so` and friends on Linux,
/// `libcef.dll` / `d3dcompiler_47.dll` / the helper executables on Windows.
/// Both the runtime library and the launcher are named after the app, so an app
/// name that resolves onto one of those would overwrite it (`fs::copy` and
/// `fs::rename` both replace silently) and ship an app that can't start.
fn reject_backend_file_collision(
  path: &Path,
  app_name: &str,
  kind: &str,
) -> Result<(), AnyError> {
  if !path.exists() {
    return Ok(());
  }
  let name = path.file_name().unwrap_or_default().to_string_lossy();
  bail!(
    "app name {app_name:?} resolves its {kind} to {name}, which is already \
     part of the app. Choose a different --output name.",
  );
}

/// The runtime dylib filename each macOS LAUFEY backend resolves when the
/// backend binary is the bundle's CFBundleExecutable (i.e. no `--runtime`
/// argument is passed). The two macOS backends use different conventions:
/// - `webview` searches a hardcoded `libruntime.dylib` via [NSBundle mainBundle]
///   (laufey `webview/src/main_mac.mm`).
/// - `cef` derives `<backend-executable-basename>.dylib` next to the binary
///   (laufey `LaufeyFindColocatedRuntime`, `cef/src/runtime_loader.cc`).
fn macos_runtime_dylib_name(backend: &str, laufey_exe_stem: &str) -> String {
  if backend == "cef" {
    format!("{laufey_exe_stem}.dylib")
  } else {
    "libruntime.dylib".to_string()
  }

View on GitHub (pinned to f7822238ca)

Solutions

1. Pick a different `--output` name that does not resolve to an existing file in the app bundle.
2. Delete or move the colliding file at the resolved path if it is stale output from a previous build.
3. Build into a fresh/clean output directory so no pre-existing files match backend filenames.

Example fix

// before
deno desktop build --output myapp   # myapp already exists as a backend file in the bundle
// after
deno desktop build --output myapp-desktop  # or delete the stale 'myapp' file first

import { existsSync } from "node:fs";
import { join } from "node:path";
// Before building, ensure the --output name won't collide with existing app files
if (existsSync(join(outputDir, outputName))) {
  throw new Error(`--output name "${outputName}" already exists in the app dir; pick another`);
}

function isFreeOutputName(dir: string, name: string): boolean {
  return !existsSync(join(dir, name));
}

try {
  await buildDesktopApp({ output: outputName });
} catch (err) {
  if (String(err.message).includes("already part of the app")) {
    console.error(`Output name "${outputName}" collides with an app file; choose a different --output name.`);
  } else {
    throw err;
  }
}

When it happens

Trigger: Calling the desktop app build with an `--output` name such that the resolved path for one of the backends' files (identified by `kind`) already exists, e.g. the output name equals an existing file of the app bundle (a previously generated binary, dylib, or other backend artifact). The check only fires when `path.exists()` is true.

Common situations: Re-running a build with an --output name that matches a file inside the app bundle rather than the bundle itself; choosing an --output name identical to an internal backend artifact (like a dylib or helper binary); migrating build configs where the output directory now contains leftover files from a previous run whose names collide.

Related errors

• Invalid deep-link scheme {scheme:?}: {reason}.
• unknown --compress format '{other}' (use xz or zstd)
• Refusing to overwrite '{}': a file with that name already ex
• Refusing to delete existing directory '{}': it was not creat
• bundle identifier is empty

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