denoland/deno · error

Package '{}' not found in catalog

Error message

Package '{}' not found in catalog

What it means

cli/args/mod.rs:504 fires during specifier resolution when a package.json dependency uses a catalog reference (deno_package_json::PackageJsonDepValue::Catalog, i.e. "pkg": "catalog:" or "catalog:<name>") but workspace_resolver.resolve_catalog_dep(alias, catalog_name) finds no matching catalog entry in the workspace's deno.json. The resolver therefore cannot turn the alias into a concrete npm:version specifier and aborts with this anyhow error.

Source

Thrown at cli/args/mod.rs:504

                sub_path.as_deref(),
                Some(cwd),
                node_resolver::ResolutionMode::Import,
                node_resolver::NodeResolutionKind::Execution,
              )?
              .into_url()?
          }
          deno_package_json::PackageJsonDepValue::Catalog(catalog_name) => {
            match self
              .workspace_resolver
              .resolve_catalog_dep(alias, catalog_name)
            {
              Some(req) => ModuleSpecifier::parse(&format!(
                "npm:{}{}",
                req,
                sub_path.map(|s| format!("/{}", s)).unwrap_or_default()
              ))?,
              None => {
                return Err(deno_core::anyhow::anyhow!(
                  "Package '{}' not found in catalog",
                  alias
                ));
              }
            }
          }
        }
      }
      deno_resolver::workspace::MappedResolution::PackageJsonImport {
        pkg_json,
      } => self
        .node_resolver
        .resolve_package_import(
          specifier,
          Some(&node_resolver::UrlOrPathRef::from_url(cwd)),
          Some(pkg_json),
          node_resolver::ResolutionMode::Import,
          node_resolver::NodeResolutionKind::Execution,

View on GitHub (pinned to 89f33cbef2)

Solutions

  1. Add the package to the catalog in the workspace-root deno.json: "catalog": { "chalk": "^5.3.0" } (or "catalogs": { "default": { ... } })
  2. Verify the catalog name matches exactly — "catalog:jsr" requires a "catalogs": { "jsr": { ... } } entry; bare "catalog:" maps to the default catalog
  3. Run `deno install` from the workspace root so the root deno.json is discovered, and upgrade Deno to a version supporting catalogs
  4. As a last resort, pin the dependency directly in package.json ("chalk": "^5.3.0") to drop the catalog indirection

Example fix

// before -- package.json
"dependencies": { "chalk": "catalog:" }
// (root deno.json has no catalog)

// after -- root denzo.json adds:
{
  "catalog": { "chalk": "^5.3.0" }
}
Defensive patterns

Strategy: validation

Validate before calling

// Node script: verify every catalog ref resolves before running deno
import { readFileSync } from "node:fs";
const pkg = JSON.parse(readFileSync("package.json", "utf8"));
const deno = JSON.parse(readFileSync("deno.json", "utf8"));
const catalog = deno.catalog ?? Object.values(deno.catalogs ?? {})[0] ?? {};
for (const [dep, spec] of Object.entries({ ...pkg.dependencies, ...pkg.devDependencies })) {
  if (typeof spec === "string" && spec.startsWith("catalog:") && !(dep in catalog)) {
    console.error(`MISSING CATALOG ENTRY for ${dep}`);
    process.exitCode = 1;
  }
}

Prevention

When it happens

Trigger: A package.json dependency like "chalk": "catalog:" while the root deno.json has no "catalog"/"catalogs" block defining chalk; a named catalog "catalog:jsr" that was never declared; running the script from outside the workspace so the deno.json defining catalogs is never discovered.

Common situations: Adopting Deno workspace catalogs after `deno add --catalog` in the wrong workspace root; teammates on older Deno versions that don't read catalogs; renaming a catalog in deno.json but leaving package.json references behind; monorepo members whose nearest deno.json lacks the inherited catalog.

Related errors


AI-assisted analysis of denoland/deno@89f33cbef2 (2026-08-16). Data as JSON: /api/errors/577f6825ea8f48e8. Report an issue: GitHub.