Let --data read the body: @<path> from a file, @- from stdin

[mattpodwysocki]

Ported from mapbox-cli-private#136, which can no longer merge there now that oss/ is a submodule (#132). CI was green there; re-verified here.

--data can now read the request body instead of carrying it:

mapbox styles create --data @style.json
jq '.name = "Renamed"' style.json | mapbox styles update STYLE_ID --data @-

Why

--data "$(cat style.json)" works on macOS and Linux and nowhere else this CLI ships to. There is no cmd.exe equivalent of $(cat …) on a platform with its own installer and CI leg; the body lands in the process table where ps shows it to other users; and it breaks at a size that fails in the shell, before mapbox runs, so no remedy string could ever be seen.

Exactly five operations take --data, so the blast radius is knowable: geocoder batch-geocode, styles create, styles update, styles draft update, sprites delete-batch.

The part that would have been silently wrong

Payload::Bounded's doc comment read:

A --data body was typed on a command line, and every operating system caps how much one of those can hold — two megabytes at the outside, which goes out inside the ordinary budget with room to spare.

Correct until this change, and exactly what @<path> breaks: BodySource::Json looks identical whether it was typed or read from a 200 MB file, and the second would have been handed a 60-second budget instead of the 900 seconds --file gets. Nothing would have failed in CI — a large body would just have timed out with an error blaming the network. payload_of now takes the provenance rather than inferring it from a body that no longer carries the distinction.

Three decisions, each with a test

• Read as text, not bytes. A JSON body has to be UTF-8, so a file that isn't says so rather than being lossily converted into a body the API rejects for reasons naming nothing the caller did.
• Sent byte for byte. The trailing newline an editor leaves is not stripped; trimming a supplied body would be the CLI editing what it was asked to send.
• An empty source names itself. Otherwise cat missing.json | mapbox … fails as EOF while parsing a value, which describes the parser rather than the pipe whose own error scrolled past.

One interaction documented rather than changed

Of the five, only sprites delete-batch is a DELETE, and a confirmation needs stdin to be a terminal — which a pipe is not, so confirm::decide returns Proceed. Piping a body therefore sends it unasked, exactly as < file always did. @<path> leaves stdin alone and keeps the prompt.

This was the one thing I'd flagged as needing a decision — whether @- must imply --yes or error. It doesn't: the thing that makes @- possible is the same thing that already suppresses the prompt.

The @ ambiguity

Only the first character decides, so --data '{"contact":"a@b.example"}' is still the body it looks like. A body whose first character is a literal @ can't be passed this way — curl has the same limitation — and it costs nothing because all five operations send JSON and @ is not valid JSON. --data-raw is the escape hatch if a text body that could start with one is ever wired up; noted in the comment rather than built for a case that doesn't exist.

Verified

548 tests, fmt and clippy clean. Before the port, against the live API: batch-geocode --data @queries.json and the same piped through @- both returned Helsinki and Tampere. Under --dry-run: the 242 KB style from the issue at 241,946 bytes, a missing file, a bare @, a directory, an empty pipe, and a non-UTF-8 file each reporting the actual mistake.

[zmofei]

LGTM — verified diff, timeout budget threading, edge-case tests, and CI (all green).