fix: Extension not formatting files

[saade]

This PR makes Pint always run with the --repair flag.

TLDR

Without this flag, Pint does not apply any formatting when executed via the VSCode extension host, even though the same command works as expected in a terminal. With --repair, Pint consistently applies fixes inside the extension.

Background & Investigation

I went through a lot of trial and error trying to understand the issue:

• Initial behavior: Pint ran fine in the terminal (with or without --repair), but in the extension it exited without formatting the file.

• What I tried:

  • Verified the cwd was correct (project root).
  • Forced execution via php vendor/bin/pint instead of relying on the shebang.
  • Tested both spawn and exec, and added listeners for stdout, stderr, exit, and close.
  • Tried with --no-cache.
  • Explicitly separated args with -- file.php.
  • Experimented with waiting for the spawn process to exit. This caused the extension to hang until I explicitly closed stdin in the child process.

• Findings:

  • Without --repair, the process appeared to run but didn’t apply changes.
  • With --repair, Pint behaved consistently and files were correctly formatted.
  • The exact reason why Pint behaves differently under Node’s spawn (non-TTY) vs. an interactive terminal remains unclear.
  • This exact issue is also present in the official Laravel VSCode extension, which recently added Pint support. Applying the same --repair flag there resolves the problem as well.

Conclusion

Although the root cause is still unknown, using --repair is the only reliable way I found to make Pint apply fixes in the VSCode extension environment. While this may be a workaround, it is functional and unblocks the extension.

[saade]

Oh, this looks like an issue with the latest version of laravel/pint 1.25.0 i can confirm that in 1.24.0 this problem does not occur.

Might be related to: laravel/pint#390

[fritz-c]

Thank you for tracking this down. I had been puzzling over it for at least an hour last night but didn't have the diagnostic know-how to trace it to that part. Anyway, I was about to submit an issue when I noticed your PR, so I got a repro ready already. May it be of use to @d8vjork when checking out this PR:
https://github.com/fritz-c/pint-1-25-issue

[saade]

Experimented with waiting for the spawn process to exit. This caused the extension to hang until I explicitly closed stdin in the child process.

---

@saade, that means that there's input on STDIN when vscode is trying to run pint
Originally posted by @calebdw in laravel/pint#390 (comment)

This makes sense, in this case we need to close STDIN manually to avoid hanging. Fixed in d7d0d6e

[d8vjork]

@saade Thanks for giving this PR and for all the effort!

Is this --repair really needed? I don't know if previous versions of Pint will support this or not

[d8vjork]

Same for @fritz-c for the replication repo! I'm gonna soon check all this, also with previous versions of Pint to not let previous Pint users down

[saade]

@d8vjork The --repair flag was introduced in v1.15.3 we're now at v1.25.1.

Pint v1.15.3 requires Laravel ^10.48.8 which is now sunsetted according to the Support Policy

Seems like a good amount of support.