Skip to content

Run first full build hides npm output and failures from the visible terminal #41

Description

@ashfame

Summary

Clicking Run first full build starts npm run build and shows a busy animation, but none of the command's stdout, stderr, or exit status appears in the visible terminal. When the process exits quickly, the animation simply stops and the user receives no explanation.

The same command typed manually into the embedded terminal displays its output correctly. This is a renderer wiring bug, not an npm or Electron output problem.

Environment where reproduced

Steps to reproduce

  1. Start the app from source.
  2. Create or open a wordpress-develop site for which the wizard enables Run first full build.
  3. Click Run first full build.
  4. Observe that the button becomes busy and then stops, while the visible terminal remains unchanged.
  5. Type npm run build manually into the embedded terminal.
  6. Observe that the same runner now prints its command, npm diagnostics, process output, and exit code.

Actual behavior

The checklist button provides no visible process output. In the reported reproduction, the hidden command failed immediately because grunt was unavailable, but the UI displayed none of this:

> WordPress@7.1.0 build
> grunt build

sh: grunt: command not found
npm verbose exit 127
npm verbose code 127
npm run build exited with code 127

The only visible signal was the busy animation ending.

Expected behavior

The checklist button should use the same visible terminal as commands entered manually. It should immediately print that the build is starting, stream stdout and stderr, display the final exit code, and leave the diagnostic history available after failure.

Code-level cause

The build checklist action calls runScript('build') without supplying terminal callbacks: https://github.com/WordPress/experimental-wp-dev-env/blob/trunk/src/renderer/index.jsx#L1392-L1405

runScript() always appends output and the final exit code to the npmLogs React state, and only forwards output to the visible terminal when an optional onLog callback is supplied: https://github.com/WordPress/experimental-wp-dev-env/blob/trunk/src/renderer/index.jsx#L865-L889

npmLogs and npmRef remain in component state, but no JSX element renders npmLogs or attaches npmRef. Output appended there is therefore invisible: https://github.com/WordPress/experimental-wp-dev-env/blob/trunk/src/renderer/index.jsx#L689-L725

By comparison, the install checklist action uses runInstallWithTerminal(), which calls writeToTerminal() for start, output, and completion: https://github.com/WordPress/experimental-wp-dev-env/blob/trunk/src/renderer/index.jsx#L925-L933

The embedded terminal's manual npm run <script> path also passes onLog and onDone callbacks to runScript(), which is why typing the command exposes the failure.

User impact

  • Real build failures look like a no-op.
  • Users cannot tell whether the command ran, failed, or was cancelled.
  • Essential diagnostics such as EBADENGINE, ENOENT, missing executables, native-module errors, and exit codes are hidden.
  • The behavior makes runtime-upgrade testing misleading because the underlying runner may be functioning correctly while the UI appears broken, or may be failing while the UI appears idle.

Suggested implementation direction

Add a runBuildWithTerminal() wrapper analogous to runInstallWithTerminal(), or make every non-background runScript() invocation write to the visible terminal by default. The checklist action should not depend on the unused npmLogs state.

Consider removing the dead npmLogs, npmRef, and npm log-stick state after all callers use the Xterm terminal, unless a second rendered log surface is intentionally restored.

Acceptance criteria

  • Clicking Run first full build writes a start message to the visible terminal.
  • stdout and stderr stream into that terminal throughout the build.
  • Success and failure exit codes are shown.
  • A fast failure remains visible after the button stops animating.
  • The behavior matches manually typing npm run build into the embedded terminal.
  • Renderer coverage verifies that checklist-triggered output reaches writeToTerminal().

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions