`miden build` fails with "expected input file", but the getting-started tutorial recommends it

[ricomateo]

The Your first smart contract tutorial instructs users to compile their miden project with miden build, but this command currently fails with "expected input file".

Compiling with cargo miden build works just fine. I discussed this with @TomasArrachea, and it appears to be an issue with midenup rather than the project itself.

It would be helpful to either fix the miden build command in midenup, or update the tutorial to recommend cargo miden build in the meantime.

How to reproduce it

Create a new project and run miden build in the project directory

miden new my-project
cd my-project/contracts/counter-account
miden build

miden build fails with an "expected input file" error:

info: current toolchain is stable and is installed
error: expected input file

Usage: midenc [OPTIONS] [FILE]

For more information, try '--help'.
Error: failed to execute 'miden build'

Caused by:
    'miden build' failed with status 2

Passing an input file explicitly, as the error message suggests, also fails:

$ miden build src/lib.rs
info: current toolchain is stable and is installed
Error:   x `rustc` returned an error when compiling the input, see stderr output for
  | more details
Error: failed to execute 'miden build src/lib.rs'
Caused by:
    'miden build src/lib.rs' failed with status 1

Environment

miden --version output:

The Miden toolchain porcelain:

Environment:
- cargo version: cargo 1.97.0-nightly (eb9b60f1f 2026-04-24).

Midenup:
- midenup + miden version: 0.3.2.
- active toolchain version: 0.15.0.
- midenup revision: .
- midenup was compiled with cargo 1.93.1 (083ac5135 2025-12-15).

[TomasArrachea]

It seems that midenup was updated so miden build is no longer an alias for cargo-miden build, rather an alias for midenc directly (0xMiden/midenup@b57b51c). I'm not sure what is the reasoning behind it but I would imagine that users are supposed to use cargo miden build now, since midenc is a lower lever tool.

cc @bitwalker

[bitwalker]

It seems that midenup was updated so miden build is no longer an alias for cargo-miden build, rather an alias for midenc directly (0xMiden/midenup@b57b51c). I'm not sure what is the reasoning behind it but I would imagine that users are supposed to use cargo miden build now, since midenc is a lower lever tool.

cargo miden build is a very thin wrapper around midenc path/to/Cargo.toml. Now that midenc can build not just Rust, but also MASM projects, miden build needs to invoke midenc rather than cargo miden build, as the latter is only for Rust.

The one oversight here is that midenc doesn't attempt to resolve a miden-project.toml if no input file path is given - that's something we can fix in the compiler. We can also modify the channel manifest for midenup to always pass miden-project.toml as an extra argument for the v0.15 toolchain, and we can make sure v0.16 addresses this issue.

Note that by passing src/lib.rs as a source file, midenc attempts to compile that as a standalone Rust source file (i.e. without Cargo), which obviously isn't what you want. You want to point midenc to either miden-project.toml (compiles based on selected project target), or Cargo.toml (will resolve the miden-project.toml path under the assumption it is in the same directory as Cargo.toml).

[huklaa]

I checked the current discussion here before proposing a docs-only workaround. Based on @bitwalker's clarification, the failure is specifically that miden build now invokes midenc, and v0.15 does not auto-resolve miden-project.toml when no input path is supplied. The project-aware forms are therefore miden build miden-project.toml (or pointing midenc/the wrapper at Cargo.toml), while miden build src/lib.rs intentionally treats the Rust file as a standalone source file and is not equivalent to a Cargo project build.

So I would avoid changing the tutorial to cargo miden build as the long-term fix, because that only covers Rust projects and would conflict with the newer MASM-capable miden build direction. A temporary docs note can instead show the explicit project manifest for v0.15, then be removed once midenup/compiler auto-resolution lands.