[petebacondarwin]

Multipart commands previously exposed only the primary binary field through --file, leaving other binary fields inaccessible. Add path-valued flags for those fields and upload their bytes under the original multipart names. Pages deployment creation now exposes --worker-js, --routes-json, --redirects, --worker-bundle, and --functions-filepath-routing-config-json; Cloudforce One asset uploads expose --source.

Keep the primary --file behavior, prevent collisions with existing flags and aliases, and include the new fields in command metadata and dry-run previews. Implemented in the current Forge generator plugin, with regression coverage for uploaded bytes, original field names, paths with spaces and Unicode, invalid files, primary-file coexistence, and mixed multipart/octet-stream selection. Includes a minor changeset for the new flags. Based on the contributor patch linked in the issue, with nahwan-kim's authorship preserved.

Validation:

• pnpm check passed, including regeneration, formatting, lint, builds, and workspace type checks.
• pnpm --filter cf test: 1,622 tests passed, 6 skipped.
• pnpm --filter @cloudflare/wrangler-tests test: 637 tests passed; existing skipped/todo cases remain.
• Three compiled CLI smoke checks passed for Pages help, Pages multipart dry-run, and Cloudforce One multipart dry-run.

Fixes #177.

[pkg-pr-new]

npm i https://pkg.pr.new/cf@272

commit: ab4adcf

[ask-bonk]

LGTM

github run

[github-actions]

cf --help startup

	mean	stddev	min	max
PR	214.1 ms	3.7 ms	207.7 ms	221.6 ms
base	213.5 ms	4.5 ms	207.0 ms	226.4 ms

Δ (PR vs base): — +0.6 ms (+0.3%)

Measured with hyperfine on ubuntu-latest (3 warmup runs, 20 timed runs). CI numbers carry ±a few ms of runner jitter; treat small deltas as noise.

[edmundhung]

I think this needs a rebase to resolve the conflict introduced from the recent refactor. I will move this back to draft first. Just ping me when it is ready 🙏🏼

[ask-bonk]

LGTM

github run

[edmundhung]

I wonder if it's worth reusing the @ syntax for multipart fields here.

As I understand, every string-typed body flag in cf already accepts an '@path/to/file' token, following curl's '-d @file' convention:

cf mtls-certificates create --certificates @./cert.pem \
   --private-key @./key.pem --ca
cf origin-ca-certificates create --csr @./csr.pem ...
cf d1 database query <id> --sql @./query.sql

What if we follow the same pattern so the behavior here could be:

--worker-js @./worker.js                 # Read the file
--worker-js 'export default { ... }'     # Send literal source