fix(install): avoid false musl detection on WSL/glibc systems

[hadronomy]

Fixes a false musl detection in the install script on glibc-based Linux systems,
especially WSL environments where musl happens to be installed.

The previous logic treated the presence of a musl loader file such as
/lib/ld-musl-x86_64.so.1 as proof that the system was musl-based. On WSL/Ubuntu,
that can be a false positive, which causes the installer to request the wrong
platform package:

vite-plus-cli-linux-x64-musl-<version>.tgz

instead of:

vite-plus-cli-linux-x64-gnu-<version>.tgz

This then fails during extraction with:

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Minimal reproduction

Environment used for reproduction:

• WSL
• glibc-based distro (Ubuntu)
• musl also installed, so /lib/ld-musl-x86_64.so.1 exists

1. Verify the environment is actually glibc-based

Run:

ldd --version | head -1
getconf GNU_LIBC_VERSION

Expected output is something like:

ldd (Ubuntu GLIBC 2.39-0ubuntu8.7) 2.39
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
glibc 2.39

This shows the correct target should be linux-x64-gnu, not linux-x64-musl.

2. Run the installer as-is

curl -fsSL https://vite.plus | bash

Observed output:

Setting up VITE+...

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

At this point the installer does not show which tarball URL failed, because the
download path uses a silent curl and tar only reports the extraction error.

3. To see the actual failing package URL, patch the installer locally

Save the installer locally, then change the curl line inside
download_and_extract() from:

curl -sL "$url" -o "$temp_file"

to:

echo "Downloading: $url" >&2
curl -fsSL "$url" -o "$temp_file"

Then run the local copy:

bash install.sh

Expected output now shows the real issue:

Setting up VITE+...
Downloading: https://registry.npmjs.org/@voidzero-dev/vite-plus-cli-linux-x64-musl/-/vite-plus-cli-linux-x64-musl-0.1.11.tgz
error: Network error (curl exit code 22)

  This may be caused by:
    - Network connectivity issues
    - Firewall or proxy blocking the connection
    - DNS configuration problems

  Failed URL: https://registry.npmjs.org/@voidzero-dev/vite-plus-cli-linux-x64-musl/-/vite-plus-cli-linux-x64-musl-0.1.11.tgz

  To debug, run:
    curl -v "https://registry.npmjs.org/@voidzero-dev/vite-plus-cli-linux-x64-musl/-/vite-plus-cli-linux-x64-musl-0.1.11.tgz"

This reveals that the installer is incorrectly inferring linux-x64-musl, and fails because there's no musl package in the registry.

4. Expected behavior

For the same environment, the installer should resolve the GNU package instead:

https://registry.npmjs.org/@voidzero-dev/vite-plus-cli-linux-x64-gnu/-/vite-plus-cli-linux-x64-gnu-0.1.11.tgz

[netlify]

✅ Deploy Preview for viteplus-preview canceled.

Name	Link
🔨 Latest commit	b3ebdb8
🔍 Latest deploy log	https://app.netlify.com/projects/viteplus-preview/deploys/69b3e68dd489c300088befa1

[Copilot]

Pull request overview

Updates the CLI installer’s libc detection logic so glibc-based Linux systems (notably WSL/Ubuntu) don’t get misclassified as musl simply because a musl loader file exists, preventing downloads of non-existent *-musl tarballs.

Changes:

• Prefer positive glibc detection via getconf GNU_LIBC_VERSION before any musl heuristics.
• Enhance ldd --version parsing to detect both musl and glibc explicitly.
• Move musl-loader-file presence check to a final fallback step.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[fengmk2]

@hadronomy https://vite.plus is in effect, thanks for the fix 🥇