BoundaryML/baml · error

no `.baml` files found in {}

Error message

no `.baml` files found in {}

What it means

load_and_compile_project opens a ProjectSession over the project directory; if the session reports no `.baml` sources at all (session.is_empty()), packing has nothing to compile and the CLI bails with the project root path in the message. `baml pack` only works on projects containing BAML source files.

Source

Thrown at baml_language/crates/baml_cli/src/pack_command.rs:299

    /// Project-mode load + compile through the bytecode cache — the same warm
    /// flow as `baml run` (`run_command::load_and_compile`): whole-program hit
    /// when nothing changed, per-file unit reuse on a dirty edit, full compile
    /// otherwise. Pack shares run/check's exact cache key space, so a pack
    /// right after a run (or a
    /// re-pack) serves the identical `Program`. The packaged bytecode is
    /// target-independent (the `--target` triple only selects the host binary
    /// bytes), and emit determinism guarantees a reused image is byte-identical
    /// to a fresh compile, so serving from cache never changes the artifact.
    fn load_and_compile_project(
        &self,
        reporter: &Reporter,
    ) -> Result<(ProjectDatabase, Program, bool)> {
        let mut session = crate::project_session::ProjectSession::open(
            self.from.as_deref(),
            crate::project_session::CacheUse::ReadWrite,
        )?;
        if session.is_empty() {
            anyhow::bail!("no `.baml` files found in {}", session.root().display());
        }
        // Mirror `baml run`'s per-file format check: probe each source through
        // the formatter and emit a single advisory if any file would change.
        let needs_format_hint = session.needs_format_hint();

        if let Some(program) = session.try_cached_program() {
            crate::bytecode_cache::cache_debug(format_args!(
                "pack: bytecode cache hit — skipping compile"
            ));
            return Ok((session.db, program, needs_format_hint));
        }

        // Seed the stdlib typed interface and prepare the per-file reuse plan —
        // the same warm-database setup run/check/test use.
        let warmth = session.warm_prep();
        let (reuse_plan, stdlib_interface_hit) = (warmth.reuse_plan, warmth.stdlib_interface_hit);
        let db = &session.db;
        let package = session.package;

View on GitHub (pinned to bd85ce9dee)

Solutions

1. cd into (or pass `--from` to) the directory that actually contains your `.baml` files.
2. Verify `.baml` files exist at the reported root: `ls <root>/**/*.baml`.
3. Ensure your project's baml source layout matches what the CLI expects (e.g. a bamlsrc/ directory) and re-run `baml pack`.

Example fix

// before
baml pack   # run in repo root with no .baml files

// after
cd ./bamlsrc
baml pack -f MyFunction

# guard: ensure .baml files exist in the pack directory
if ! find "${PACK_DIR:-.}" -name '*.baml' | grep -q .; then
  echo "no .baml files in ${PACK_DIR:-.}" >&2; exit 2
fi
baml pack --from "$PACK_DIR" -f "$FUNC"

When it happens

Trigger: Running `baml pack` from (or with `--from` pointing to) a directory that contains zero `.baml` files.

Common situations: Running the command from the wrong working directory (repo root instead of the bamlsrc project, or vice versa); a misconfigured `--from` path; a checkout where BAML sources live elsewhere; typos in the project directory.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

• no baml.toml found from {} up to the home directory Run this
• positional `<TARGET>` and `-f/--function` are mutually exclu
• no target specified. Pass a positional `<TARGET>` to pack on
• compilation failed: {e:?}
• two targets share subcommand name `{}` (`{}` and `{}`). Subc

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/1f3064bde442e701. Report an issue: GitHub.