[Feature] Add profiling to app function run

[davejcameron]

WHY are these changes introduced?

Function Runner supports generating WebAssembly performance profiles, but shopify app function run does not expose that capability.

Profiles are also difficult to interpret when the built WebAssembly module does not contain function names.

WHAT is this pull request doing?

• Adds a --profile flag to shopify app function run and forwards it to Function Runner.
• Documents that the generated profile can be viewed in Speedscope.
• Warns before profiling when the built module does not contain a WebAssembly function name section.
• Provides separate guidance for JavaScript functions, whose Javy output does not include function names regardless of the wasm_opt setting.
• Updates the generated command manifest and README.

How to test your changes?

1. Build a function.
2. Run shopify app function run --profile with a valid input.
3. Confirm the function runs and a .perf profile is generated.
4. Open the profile in Speedscope.
5. Run the command with a module that has no function name section and confirm the warning is shown.

Validation performed:

• pnpm --filter @shopify/app vitest run src/cli/services/function/runner.test.ts
• pnpm --filter @shopify/app lint
• pnpm --filter @shopify/app type-check
• pnpm refresh-manifests

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing and includes a minor changeset

[Copilot]

🟡 Not ready to approve

The new profiling warning code can throw during best-effort module inspection and should not be able to prevent shopify app function run --profile from running.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

Adds a profiling workflow to shopify app function run so developers can generate WebAssembly performance profiles locally, with additional UX to help interpret profiles when function names are missing.

Changes:

• Introduces a --profile flag on shopify app function run and forwards it to Function Runner.
• Adds a pre-run warning when profiling will likely produce <unknown> frames due to missing WebAssembly name data (with special guidance for JavaScript/Javy).
• Updates docs/manifest output and adds tests + a changeset for the user-facing feature.

File summaries

File	Description
packages/cli/README.md	Documents the new --profile flag and Speedscope viewing guidance.
packages/cli/oclif.manifest.json	Updates generated CLI manifest to include the new flag metadata.
packages/app/src/cli/services/function/runner.ts	Adds profile option forwarding and best-effort warning logic based on WASM name section presence.
packages/app/src/cli/services/function/runner.test.ts	Adds coverage for warning behavior when profiling with/without function names (including JS/Javy scenario).
packages/app/src/cli/commands/app/function/run.ts	Adds the --profile flag to the command and passes it through to runFunction.
.changeset/profile-function-runs.md	Declares a minor bump for @shopify/app to ship the new profiling capability.

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 1
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟡 Not ready to approve

There’s a small but potentially typecheck-breaking typed-array generic assertion in runner.ts that should be simplified to the native Buffer returned by readFileSync.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (1)

packages/app/src/cli/services/function/runner.ts:48

• readFileSync already returns a Buffer (which is a Uint8Array), so the as Uint8Array<ArrayBuffer> assertion is unnecessary and introduces a typed-array generic that isn’t used elsewhere in the repo (and may not typecheck depending on TS/lib settings). Keeping the native Buffer type here is simpler and avoids masking type issues.

    const moduleBytes = readFileSync(functionPath) as Uint8Array<ArrayBuffer>
    if (!WebAssembly.validate(moduleBytes)) return

• Files reviewed: 6/7 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.