blog.naokihaba.com

OSS activity in September 2026

At the end of September, Vite+ 1.0 was released (release notes)! In September, I mainly fixed bugs in the Vite+ CLI and improved setup-vp.

voidzero-dev/vite-plus

fix(cli): handle broken pipes in command output (#2785)

When I passed the output to head like this, vp exited abnormally with exit code 134 (#2661).

vp --version | head -n 1

When head closes stdout first, println! panics with BrokenPipe. Vite+ builds with panic = "abort", so the process stops right away.

Using Oxc’s print_and_flush as a reference, I added a function for output. If the error is BrokenPipe, the function ends normally. If the error is Interrupted or WouldBlock, it retries. For other errors, it returns the error to the caller.

Pipe the output of vp –version to head -n 1. After head reads one line, it closes the pipe first, so the later write by vp fails. Before the change, println! panics with BrokenPipe. Because Vite+ builds with panic = “abort”, the process stops with exit code 134. After #2785, the output function ends normally on BrokenPipe, retries on Interrupted and WouldBlock, and returns other errors to the caller.

I also considered restoring the default handler for SIGPIPE. However, this changes the behavior of the whole process. The process could then stop before post-processing. Inside #[tokio::main], it is also too late to set it. A race with threads cannot be avoided. So I decided to handle BrokenPipe at the place where the write happens.

refactor: make global CLI stdout broken-pipe safe (#2793)

This is a follow-up to #2785. I replaced the print! and println! calls that were left in vp_global_cli and vp_shared with the same function. I also removed the setting that allowed clippy::print_stdout across the whole crate. Now CI can detect a direct println! call, even if an AI agent writes one.

ci: load generated environment before install doctor checks (#2790)

In CI for #2785, vp env doctor failed on Windows. #2758 added a shim directory for fallback use. vp env doctor also checks whether that directory is in PATH. However, the workflow that verifies the installation adds only ~/.vite-plus/bin to GITHUB_PATH. This mismatch came to light when v1.0.0-rc.0 was published. I fixed the workflow so that it loads ~/.vite-plus/env before it runs vp env doctor.

docs: clarify Nushell XDG startup requirements and recovery (#2704)

I noticed that when XDG_DATA_HOME is changed in Nushell’s config.nu, Vite+ settings are not loaded in new sessions. So I opened an issue (#2491). Nushell decides the autoload directory before it runs config.nu. So if XDG_DATA_HOME changes after that, the installer writes settings to a different place than the one Nushell reads.

If Nushell starts with XDG_DATA_HOME=A, its autoload location is set under A. Then config.nu changes XDG_DATA_HOME to B. The installer writes Vite+ settings under B. Nushell reads only the directory under A, so the Vite+ settings are not loaded.

The Nushell documentation says that XDG variables must be set before Nushell starts. I also looked at several ways for the installer to handle this. However, each one either solves only part of the problem or shows unneeded warnings, even to users who have set things up correctly. So I left the installer as it is. I wrote this requirement and the workaround in Getting Started.

docs: clarify migration dependency retention for pnpm (#2660)

I changed the migration prompt on the website to match the pnpm description in vp help migrate (#2656). The vite and vitest dependencies that vp migrate creates are kept, not removed.

docs: update homepage pack demo for the 1.0 release (#2844)

The vp pack demo on the homepage still showed the output from the old tsdown 0.14.1. So I updated it to show the actual output of vp pack in Vite+ 1.0.

voidzero-dev/setup-vp

feat: add cache-save input for restore-only caching (#140)

I added a cache-save input (#139). It is for a setup that reads the cache on every branch, but updates it only on trusted branches. The default is true, so the behavior of existing workflows does not change. If you set it to false, the action only restores the cache and does not save it. Azure Pipelines and GitLab handle caches with their own settings, so this input has an effect only in GitHub Actions.

On the main branch, cache-save set to true (the default) restores the cache and saves it at the end. On a PR branch, cache-save set to false only restores the cache and does not save it. Works only in GitHub Actions.

refactor: centralize Windows platform checks (#165)

The process.platform === "win32" check was spread across several modules (#157). So I consolidated it into one shared function, isWindows.

docs: update checkout examples to v7 (#144)

I updated the actions/checkout examples in the README to v7.