denoland/deno · critical

expected @deno/deploy to be published

Error message

expected @deno/deploy to be published

What it means

The `deploy` subcommand bootstraps itself by fetching @deno/deploy's meta.json from the JSR registry and resolving the latest published version, then runs that package as the deploy CLI. If the fetched metadata yields no eligible version, resolve_deploy_cli_version() returns None and .expect() panics with 'expected @deno/deploy to be published'.

Source

Thrown at cli/tools/deploy.rs:78

    let file = factory
      .file_fetcher()?
      .fetch_with_options(
        &registry_url.join("@deno/deploy/meta.json").unwrap(),
        deno_resolver::file_fetcher::FetchPermissionsOptionRef::AllowAll,
        deno_resolver::file_fetcher::FetchOptions {
          // jsr.io serves meta.json with `cache-control: max-age=60`, so
          // respect those headers rather than pinning the first cached copy
          // forever (see denoland/deno#35736).
          maybe_cache_setting: Some(
            &deno_cache_dir::file_fetcher::CacheSetting::RespectHeaders,
          ),
          ..Default::default()
        },
      )
      .await?;
    let info = serde_json::from_slice::<JsrPackageInfo>(&file.source)?;
    let latest_version = resolve_deploy_cli_version(&info)
      .expect("expected @deno/deploy to be published");
    Url::parse(&format!("jsr:@deno/deploy@{latest_version}"))
      .map_err(ResolveUrlOrPathError::UrlParse)?
  };

  let worker_factory =
    Arc::new(factory.create_cli_main_worker_factory().await?);

  let mut worker = worker_factory
    .create_custom_worker(
      WorkerExecutionMode::Deploy,
      specifier,
      vec![],
      vec![],
      PermissionsContainer::allow_all(
        factory.permission_desc_parser()?.clone(),
      ),
      vec![ops::deploy::deno_deploy::init()],
      Default::default(),

View on GitHub (pinned to 9ad36f7a2c)

Solutions

1. Unset or fix registry overrides (DENO_REGISTRY_URL and related JSR env vars) so real jsr.io metadata is used
2. Clear cached registry metadata (fresh DENO_DIR, or delete the cached deps) and retry
3. Check https://jsr.io/@deno/deploy to confirm the package and its versions are visible
4. When developing the deploy CLI itself, set DENO_DEPLOY_CLI_SPECIFIER to a local copy to bypass registry resolution

Example fix

# before
DENO_REGISTRY_URL=https://mirror.internal/jsr deno deploy

# after - use the real registry or a complete mirror
deno deploy

curl -sL https://jsr.io/@deno/deploy/meta.json -o /tmp/deploy-meta.json
deno eval "const m = JSON.parse(Deno.readTextFileSync('/tmp/deploy-meta.json')); console.log(Object.keys(m.versions ?? {}));"
# must list at least one version before `deno deploy` will bootstrap

When it happens

Trigger: Running `deno deploy` when the fetched @deno/deploy meta.json lists no usable versions: a jsr.io outage or replication lag, a custom registry override that does not mirror the package, or a stale cached copy of meta.json.

Common situations: Corporate proxies or private JSR mirrors without @deno/deploy; transient jsr.io incidents; a poisoned DENO_DIR cache; network middleboxes returning an empty but valid JSON document.

Related errors

• No latest version for {registry_name}
• Either `node` or `range` must be provided when reporting an
• Invalid range. Start value is bigger than end value: [${star
• {}
• No versions for {registry_name}

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