[gonzaloriestra]

WHY are these changes introduced?

Fixes https://github.com/shop/issues-develop/issues/24315.

Function replay watches by default, but currently rejects --json unless --no-watch is supplied.

WHAT is this pull request doing?

Add a typed JSONL watch stream with lifecycle, rebuild, and execution records. Keep diagnostics on stderr and preserve native runner fields and numeric tokens inside execution results. Recoverable build and Function failures keep watching; fatal failures stop the session. Cancellation waits for the watcher, builds, and runner to finish.

The finite --no-watch --json result and text watch UI stay compatible. Help and schema discovery describe both output modes.

Representative text output:

Input
{}
Output
{"operations":[]}

JSON watch output:

{"type":"status","timestamp":"2026-10-26T09:00:00Z","status":"watching"}
{"type":"execution","timestamp":"2026-10-26T09:00:00Z","result":{"name":"function.wasm","size":1,"memory_usage":64,"instructions":1000,"logs":"","input":{},"output":{"operations":[]},"success":true},"exitCode":0}

Declare the replay JSON schema as a static field.

How to manually test your changes?

1. In an app with a saved Function log, run pnpm shopify app function replay --path <function-directory> --log <log-identifier> --json --no-input > replay.jsonl 2> replay.stderr.
2. Edit the Function, introduce a build error, then fix it. Check that stdout contains separate records and stderr contains diagnostics while replay keeps watching.
3. Press Ctrl-C. Check the cancellation record and exit code 130. Repeat with --no-watch --json to inspect the single native result, and without --json to inspect the terminal UI.
4. Run pnpm shopify app function replay --json-schema to inspect both contracts without starting replay.

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 — I've identified the correct bump types and added a changeset (minor for CLI streaming support, patch for CLI Kit process cancellation).

[gonzaloriestra]

/snapit

[github-actions]

🫰✨ Thanks @gonzaloriestra! Your snapshot has been published to npm.

Built from 4d405832937748e45bf0ff630841005ac064d51a. Workflow run.

Test the snapshot by installing your package globally:

pnpm i -g --@shopify:registry=https://registry.npmjs.org @shopify/cli@0.0.0-snapshot-20261027114600

Caution

After installing, validate the version by running shopify version in your terminal.
If the versions don't match, you might have multiple global instances installed.
Use which shopify to find out which one you are running and uninstall it.

[gonzaloriestra]

/snapit

[github-actions]

🫰✨ Thanks @gonzaloriestra! Your snapshot has been published to npm.

Built from 83d41bbf92ff25a6cef779b9a771e0a94daa0229. Workflow run.

Test the snapshot by installing your package globally:

pnpm i -g --@shopify:registry=https://registry.npmjs.org @shopify/cli@0.0.0-snapshot-20261027123425

Caution

After installing, validate the version by running shopify version in your terminal.
If the versions don't match, you might have multiple global instances installed.
Use which shopify to find out which one you are running and uninstall it.

[github-actions]

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/public/node/base-command.d.ts

@@ -13,7 +13,7 @@ export interface NonTTYFlagRequirement {
 declare abstract class BaseCommand extends Command {
     static baseFlags: FlagInput<{}>;
     static descriptionWithMarkdown?: string;
-    static get jsonOutputSchema(): JsonOutputSchema | undefined;
+    static jsonOutputSchema?: JsonOutputSchema;
     static get requiresSyncAnalytics(): boolean;
     static nonTTYFlagRequirements(_flags: FlagOutput): NonTTYFlagRequirement[];
     static descriptionForHelp(): string | undefined;

[isaacroldan]

Found two issues with watcher readiness and build cancellation.

---

🤖 Generated by the review-pr skill

[isaacroldan]

[P2] watching is emitted before Chokidar finishes its initial scan, so the first edit can be missed. I reproduced this with a real watcher: an edit right after the record did nothing, while a second edit after ready triggered a rebuild. Can we wait for Chokidar's ready event here and add a test for an edit immediately after watching?

---

🤖 Generated by the review-pr skill

[gonzaloriestra]

Fixed. FileWatcher.start() now waits for Chokidar’s ready event before replay emits watching. Startup also settles on cancellation or scan errors. Added a real-watcher regression that edits the Function immediately when watching is emitted and verifies a rebuild and second execution.

[isaacroldan]

[P2] If Ctrl-C arrives while a rebuild is waiting for .build-lock, the build still starts once the lock is released. exec() only listens for future abort events, so it misses the earlier abort, and this wait keeps replay open until the new command finishes. I reproduced this through watchReplay with a real lock and subprocess. Can we make the lock wait cancellable and check for an already-aborted signal before starting the build?

---

🤖 Generated by the review-pr skill

[gonzaloriestra]

Fixed. Lock retries now use abortable waits, with signal checks before and after lock acquisition and between build stages. exec() also skips commands whose signal is already aborted. Added real-lock and subprocess coverage for cancellation while blocked, cancellation on acquisition, and a successful build after the lock is released.