FuelLabs/sway · error · anyhow::Error

dependency of {:?} named {:?} is invalid: {}

Error message

dependency of {:?} named {:?} is invalid: {}

What it means

Thrown while forc walks the dependency graph during fetch/build planning: after adding an edge to a dependency node, it calls validate_dep_manifest on the dependency's manifest. If that validation fails (malformed tables, invalid entries, missing sections), the error is wrapped with the parent package name and the dependency name, so the failing edge of the graph is identified.

Source

Thrown at forc-pkg/src/pkg.rs:1526

                added.insert(dep_node);
                *entry.insert(dep_node)
            }
        };

        let dep_edge = Edge::new(dep_name.to_string(), dep_kind.clone());
        // Ensure we have an edge to the dependency.
        graph.update_edge(node, dep_node, dep_edge.clone());

        // If we've visited this node during this traversal already, no need to traverse it again.
        if !visited.insert(dep_node) {
            continue;
        }

        let dep_pinned = &graph[dep_node];
        let dep_pkg_id = dep_pinned.id();
        validate_dep_manifest(dep_pinned, &manifest_map[&dep_pkg_id], &dep_edge).map_err(|e| {
            let parent = &graph[node];
            anyhow!(
                "dependency of {:?} named {:?} is invalid: {}",
                parent.name,
                dep_name,
                e
            )
        })?;

        let path_root = match dep_pinned.source {
            source::Pinned::Member(_)
            | source::Pinned::Git(_)
            | source::Pinned::Ipfs(_)
            | source::Pinned::Registry(_) => dep_pkg_id,
            source::Pinned::Path(_) => path_root,
        };

        // Fetch the children.
        added.extend(fetch_deps(
            fetch_id,

View on GitHub (pinned to 47e5e902fa)

Solutions

  1. Read the tail of the message: the text after 'is invalid:' is the underlying validate_dep_manifest cause - fix that in the named dependency's Forc.toml
  2. Verify the dependency key in [dependencies] exactly matches the [project].name inside the dependency's own Forc.toml
  3. If the dependency comes from git/ipfs, update to a rev/tag/cid where its manifest is valid for your forc version
  4. Re-run forc build (or forc check) from the workspace root to confirm the whole graph validates

Example fix

# dependency's Forc.toml - before
[project]
authros = ["me"]
name = "my_lib"

# after
[project]
authors = ["me"]
name = "my_lib"
entry = "lib.sw"
Defensive patterns

Strategy: try-catch

Try / catch

match forc_pkg::build_with_options(&opts) {
    Ok(built) => { /* ... */ }
    Err(e) if e.to_string().starts_with("dependency of") => {
        // message contains parent pkg name, dep name and root cause after 'is invalid:'
        eprintln!("invalid dependency manifest: {e:#}");
        std::process::exit(1);
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Building any manifest whose dependency (path, git, ipfs, registry or workspace member) has a Forc.toml that fails validate_dep_manifest - e.g. a misspelled table key, a dependency entry missing required fields, or an invalid [project] section inside the dependency's manifest.

Common situations: Adding a git or path dependency whose Forc.toml is malformed or written for a different forc version; editing a workspace member's manifest while other packages depend on it; upgrading forc which tightened manifest validation rules.

Related errors


AI-assisted analysis of FuelLabs/sway@47e5e902fa (2026-08-16). Data as JSON: /api/errors/8ff9fcdfdd91f7d1. Report an issue: GitHub.