fix(pm): postinstall OS detection for Windows kernel-version drift#2883
Merged
fix(pm): postinstall OS detection for Windows kernel-version drift#2883
Conversation
The postinstall scripts relied on $OSTYPE to detect Windows, which is not set when sh is invoked from PowerShell on GitHub Actions. They then fell back to `uname -s | tr` and emitted package names like `@utoo/utoo-mingw64_nt-10.0-26100-x64`, which don't exist on npm. Recently `windows-latest` was upgraded from Server 2022 (`mingw64_nt-10.0-20348`) to Server 2025 (`mingw64_nt-10.0-26100`), making the failure visible (e.g. eggjs/egg CI), but the detection was already fragile — any future kernel bump would break it again. Switch to `uname -s` prefix matching (`MINGW*`/`MSYS*`/`CYGWIN*`) with the `$OSTYPE` check kept as a fallback, so the resolved OS is always `win32` regardless of the host kernel version. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the post-install script templates to improve Windows environment detection by utilizing uname -s and a case statement, which prevents kernel version bumps from affecting package names. The review feedback suggests adding a fallback value for the OS variable in cases where uname -s returns an empty string to ensure the generated package name is always well-formed.
Per review feedback: if `uname -s` fails or returns empty (and $OSTYPE is not a Windows variant), the resulting OS would be empty and produce a malformed package name like `@utoo/utoo--x64`. Substitute "unknown" so the failure mode is at least debuggable. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Lock down `vendor/templates/postinstall*.sh.template`'s OS/ARCH resolution so a future kernel-version bump on `windows-latest` (the trigger for the original regression here) or a stray refactor of the `uname -s` / $OSTYPE handling fails CI instead of producing a 404 package name in user installs. The test stubs `uname` and the side-effecting commands (cp, mkdir, chmod, npm, find_node_modules) and runs each template under a sandboxed sh, then asserts the computed (OS, ARCH) for 11 cases per template: Linux/macOS x64+arm64, Windows under MINGW (Server 2022 + 2025), MSYS, CYGWIN, ARM64, the legacy $OSTYPE=msys fallback, and the empty-uname "unknown" fallback. Wired into pm-ci.yml as a pre-build step on every matrix host (linux/mac/windows) — runs in well under a second. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
postinstall.sh/postinstall.utoo.shtemplates relied on$OSTYPEto detect Windows. Whenshis invoked from PowerShell on GitHub Actions,$OSTYPEis not set, so the scripts fell back touname -s | trand produced package names like@utoo/utoo-mingw64_nt-10.0-26100-x64, which don't exist on npm.windows-latestfrom Server 2022 (kernelmingw64_nt-10.0-20348) to Server 2025 (mingw64_nt-10.0-26100), so the kernel-version slug changed and the install started failing on downstream projects (e.g. eggjs/egg CI).uname -sprefix matching (MINGW*/MSYS*/CYGWIN*) and keep the existing$OSTYPEcheck as a secondary fallback, so the resolved OS is alwayswin32regardless of host kernel version.Repro (before this PR)
On a fresh
windows-latestrunner:→ postinstall builds
@utoo/utoo-mingw64_nt-10.0-26100-x64→ npm 404.Test plan
ut install --from pnpmsucceeds onwindows-latestafter this template ships in a newutoorelease.linux-x64/darwin-arm64etc. (no behavior change on those branches —uname -sprefix only matches the three Windows shell envs).🤖 Generated with Claude Code