[Feature]: Stream child_process.spawn output to extensions during execution

[wu-liang]

What should it do?

Deliver child_process.spawn stdout and stderr chunks to Raycast extensions while the child process is running, before exit/close. A command such as Ookla Speedtest's --progress should be able to update a Detail view during download and upload, rather than showing all samples only after the test finishes.

This is currently documented as unsupported in extension compatibility: “Live child_process.spawn output” arrives only once the command finishes. In 0.11.3, ExtensionAsyncProcess.Child.collect reads each pipe to EOF and proc.wait returns one result. BufferedChildProcess in Scripts/raycast-runtime/src/node-shims.js then calls stdout.end(...) and stderr.end(...) from that final result. A stdout.on("data", ...) listener therefore cannot observe intermediate progress.

A minimal repro is a view extension that spawns /bin/sh -c 'printf "first\n"; sleep 3; printf "second\n"', appends each stdout chunk to a Detail, and starts a timer. In Node, “first” appears immediately; in Tinycast both lines appear after the three-second sleep.

Suggested implementation direction: drain stdout and stderr concurrently from the native Pipes and bridge ordered chunks to the JS ChildProcess streams as they arrive. Keep exit/close after the streams drain, and preserve the current timeout, kill, detached-process, and error behavior. This would replace the current final-buffer-only path for spawn; exec/execFile could still collect their final result.

Why does it belong in Tinycast?

The Speedtest extension already asks its CLI for progress, but Tinycast does not deliver the process output until completion. This caused the apparent “blank/idle until the end” report in #743. The missing behavior is in Tinycast's Node compatibility layer, so updating Speedtest alone cannot make a normal spawn().stdout.on("data") listener receive live chunks.

I verified a local workaround by redirecting the CLI's output to a progress file and polling that file from the extension every 200 ms. It restores live speed updates without changing Tinycast, but it is extension-specific and bypasses ordinary spawn streaming. Once progress is visible, a separate Markdown SVG rendering issue can cause the circular gauge to flicker; that is tracked in #1084. The two changes solve different layers of the same user-facing experience.

Contribution

• I'm willing to work on the native/JS streaming bridge once this issue is labelled approved.

[github-actions]

Thanks for opening this.

A few things worth knowing up front:

Tinycast aims to stay small and focused, so it is extremely selective about new
features. Every request is read, and the ideas that truly matter are the ones taken on.
Smaller conveniences are usually closed.

Warning

Don't write code for this yet. This issue has to be labelled approved first.

1. Wait for a maintainer to add the approved label. That label is the only green light —
   a reply, a reaction or silence is not one.
2. Once it's there, open your pull request with Closes #1093 in the description.
3. A pull request whose linked issue isn't approved is closed automatically, unreviewed.

Docs-only changes (*.md, docs/, website/) skip this and need no approval.

Thanks for opening this! A maintainer will take a look soon.

[abue-ammar]

what? tell me in human words with screenshot

[wu-liang]

Sorry for making this confusing. The problem is that Raycast's Speedtest extension runs in Tinycast, but the speed readings only appear when the test finishes, so you cannot watch the speed change during the test.

I've now built Speedtest Live, using a different update method that works with stock Tinycast 0.11.3.

Here is the adapted version: