denoland/deno · error

could not find ' ' backend binary under (set via )

Error message

could not find '{backend}' backend binary under {} (set via {})

What it means

When the LAUFEY_DEV_DIR environment variable is set, `deno desktop` uses that laufey source checkout instead of downloading a release, resolving the backend binary with locate_dev_backend_binary(). This error means the env var pointed at a directory that contains no buildable/located binary for the requested backend — typically a checkout that has not been cargo-built yet.

Solutions

  1. Build the backend in the dev checkout: run laufey's own build (e.g. cargo build --release) inside $LAUFEY_DEV_DIR so the expected binary layout exists.
  2. If you did not intend dev mode, unset LAUFEY_DEV_DIR and re-run to fall back to the cached/download path.
  3. Verify the path actually points at a laufey checkout (look for its Cargo.toml and build output dirs) and fix the env var.
  4. Request the same backend you built for in the dev checkout.

Example fix

# before
export LAUFEY_DEV_DIR=~/src/laufey   # fresh clone, never built
deno desktop
# error: could not find 'wry' backend binary under /home/me/src/laufey (set via LAUFEY_DEV_DIR)

# after — option A: build it
(cd ~/src/laufey && cargo build --release) && deno desktop
# after — option B: leave dev mode
unset LAUFEY_DEV_DIR && deno desktop
Defensive patterns

Strategy: validation

Validate before calling

# If LAUFEY_DEV_DIR is set, assert the checkout actually contains the backend build
if [ -n "$LAUFEY_DEV_DIR" ]; then
  find "$LAUFEY_DEV_DIR" -type f -name '*laufey*' -perm -u+x | head -1 >/dev/null \
    || { echo "LAUFEY_DEV_DIR set but no built backend found — run cargo build or unset it"; exit 1; }
fi

Prevention

When it happens

Trigger: LAUFEY_DEV_DIR is exported (e.g. to hack on laufey) but the checkout has never been built, was cleaned with cargo clean, or was built only for a different backend than the one requested on the command line.

Common situations: A developer exports LAUFEY_DEV_DIR in their shell profile, then clones a fresh laufey checkout and forgets `cargo build`; CI caches a dev dir but the build step was skipped; the env var survived from an old experiment and now shadows the working download path.

Related errors


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

Appendix: source

Thrown at cli/tools/desktop.rs:2090

      );
    }

    Ok(dir)
  }

  /// Locate the LAUFEY backend binary for `backend` on `target`.
  ///
  /// Resolution order: `LAUFEY_DEV_DIR` checkout → cached download →
  /// fresh download.
  async fn find_binary(
    &self,
    backend: &str,
    target: &str,
  ) -> Result<PathBuf, AnyError> {
    if let Some(dev_dir) = laufey_dev_dir() {
      let binary =
        locate_dev_backend_binary(&dev_dir, backend).ok_or_else(|| {
          deno_core::anyhow::anyhow!(
            "could not find '{backend}' backend binary under {} (set via {})",
            dev_dir.display(),
            LAUFEY_DEV_DIR_ENV
          )
        })?;
      // Re-sign the dev laufey build so its identifier matches the bundle
      // id — same fix as the download path, applied every launch
      // because a fresh `cargo build` of laufey restores the linker's
      // default `Identifier=laufey`. The harmonize call is idempotent:
      // already-correct binaries are skipped.
      #[cfg(target_os = "macos")]
      if let Some(laufey_app) = laufey_app_for_binary(&binary)
        && let Err(e) = harmonize_laufey_app_identifiers(&laufey_app)
      {
        log::warn!(
          "[desktop] could not re-sign dev laufey backend: {e} \
           (notifications may not work in HMR mode)"
        );

View on GitHub (pinned to f7822238ca)