Uh oh!
There was an error while loading. Please reload this page.
feat(pm): support vite install - #43
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
036908a to
991b167CompareUh oh!
There was an error while loading. Please reload this page.
Brooooooklyn
commented
Aug 21, 2025
cursor review |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
767d731 to
2d82301Comparea13f86f to
75cecb1Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
75cecb1 to
eefb7a7CompareUh oh!
There was an error while loading. Please reload this page.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
d6f50d8 to
7f3a282Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
close ENG-1180 🤖 Code with [Claude Code](https://claude.ai/code)
Add support for detecting package managers through configuration files: - Detect .yarnrc.yml alongside yarn.lock for Yarn detection - Add pnpmfile.cjs detection (returns pnpm@latest) - Add yarn.config.cjs detection (returns yarn@latest, Yarn 2.0+) The detection priority follows the spec in vite-install.md: 1. packageManager field in package.json 2. pnpm-workspace.yaml / pnpm-lock.yaml 3. yarn.lock / .yarnrc.yml 4. package-lock.json 5. pnpmfile.cjs (new) 6. yarn.config.cjs (new) Tests added to verify correct detection priority and functionality. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Builds a single shared reqwest::Client in vite_shared that honors HTTPS_PROXY / HTTP_PROXY / NO_PROXY, loads PEM bundles from SSL_CERT_FILE and NODE_EXTRA_CA_CERTS, and exposes a VP_INSECURE_TLS diagnostic opt-in. Routes every existing reqwest::get / Client::new site in vite_install and vite_js_runtime through it so vp can traverse TLS-intercepting tools like Socket Firewall Free (sfw) and corporate MITM proxies. Adds an install-e2e-test-sfw job (Linux/macOS/Windows) that downloads the upstream sfw binary and runs `sfw vp i -g pnpm@9.15.0` plus `sfw vp install` against vitejs/vite. Gated on the `test: sfw` label for PRs, unconditional on push-to-main. Carries VP_INSECURE_TLS=1 until sfw upstream ships the EKU fix (SocketDev/sfw-free#30, #43); flip removed once that lands to also exercise CA injection. Refs voidzero-dev/setup-vp#73
Verified locally with sfw 0.12.22: the CA cert sfw issues has no Extended Key Usage extension at all (Basic Constraints CA:TRUE + Key Usage critical Certificate Sign), which rustls and native-tls accept per RFC 5280. The original bug (SocketDev/sfw-free#30, #43) — a present-but-empty EKU that rustls rejected — appears to have been fixed upstream. Removing VP_INSECURE_TLS=1 lets this CI job exercise the full CA-injection path (SSL_CERT_FILE -> Certificate::from_pem -> add_root_certificate -> TLS handshake) end-to-end, not just the proxy plumbing. Local reproduction: $ cat /tmp/p/package.json { "name":"sfw-tls-test", "packageManager":"pnpm@9.15.0" } $ rm -rf ~/.vite-plus/package_manager/pnpm/9.15.0* $ unset VP_INSECURE_TLS $ sfw vp install --no-frozen-lockfile Protected by Socket Firewall === Socket Firewall === 1 packages fetched successfully $ ls ~/.vite-plus/package_manager/pnpm/9.15.0/ -> pnpm
Two regressions surfaced in the last CI run: 1. Linux failed with `Failed to download from nodejs.org` — sfw's GitHub release v1.10.0 still issues a CA with a present-but-empty Extended Key Usage, which rustls rejects. My local verification used `sfw` from npm (0.12.x, separate version track) which doesn't carry the bug; the GitHub releases (what CI downloads) do. Restore VP_INSECURE_TLS=1 on this step until SocketDev/sfw-free#30 / #43 are released. 2. Windows failed with `Command 'vp.cmd' not found in PATH`. vp on Windows ships as `vp.exe` (the trampoline), not `vp.cmd`. sfw's earlier "try vp.cmd" suggestion was a generic PATHEXT hint.
Builds a single shared reqwest::Client in vite_shared that honors HTTPS_PROXY / HTTP_PROXY / NO_PROXY, loads PEM bundles from SSL_CERT_FILE and NODE_EXTRA_CA_CERTS, and exposes a VP_INSECURE_TLS diagnostic opt-in. Routes every existing reqwest::get / Client::new site in vite_install and vite_js_runtime through it so vp can traverse TLS-intercepting tools like Socket Firewall Free (sfw) and corporate MITM proxies. Adds an install-e2e-test-sfw job (Linux/macOS/Windows) that downloads the upstream sfw binary and runs `sfw vp i -g pnpm@9.15.0` plus `sfw vp install` against vitejs/vite. Gated on the `test: sfw` label for PRs, unconditional on push-to-main. Carries VP_INSECURE_TLS=1 until sfw upstream ships the EKU fix (SocketDev/sfw-free#30, #43); flip removed once that lands to also exercise CA injection. Refs voidzero-dev/setup-vp#73
Verified locally with sfw 0.12.22: the CA cert sfw issues has no Extended Key Usage extension at all (Basic Constraints CA:TRUE + Key Usage critical Certificate Sign), which rustls and native-tls accept per RFC 5280. The original bug (SocketDev/sfw-free#30, #43) — a present-but-empty EKU that rustls rejected — appears to have been fixed upstream. Removing VP_INSECURE_TLS=1 lets this CI job exercise the full CA-injection path (SSL_CERT_FILE -> Certificate::from_pem -> add_root_certificate -> TLS handshake) end-to-end, not just the proxy plumbing. Local reproduction: $ cat /tmp/p/package.json { "name":"sfw-tls-test", "packageManager":"pnpm@9.15.0" } $ rm -rf ~/.vite-plus/package_manager/pnpm/9.15.0* $ unset VP_INSECURE_TLS $ sfw vp install --no-frozen-lockfile Protected by Socket Firewall === Socket Firewall === 1 packages fetched successfully $ ls ~/.vite-plus/package_manager/pnpm/9.15.0/ -> pnpm
Two regressions surfaced in the last CI run: 1. Linux failed with `Failed to download from nodejs.org` — sfw's GitHub release v1.10.0 still issues a CA with a present-but-empty Extended Key Usage, which rustls rejects. My local verification used `sfw` from npm (0.12.x, separate version track) which doesn't carry the bug; the GitHub releases (what CI downloads) do. Restore VP_INSECURE_TLS=1 on this step until SocketDev/sfw-free#30 / #43 are released. 2. Windows failed with `Command 'vp.cmd' not found in PATH`. vp on Windows ships as `vp.exe` (the trampoline), not `vp.cmd`. sfw's earlier "try vp.cmd" suggestion was a generic PATHEXT hint.
Builds a single shared reqwest::Client in vite_shared that honors HTTPS_PROXY / HTTP_PROXY / NO_PROXY, loads PEM bundles from SSL_CERT_FILE and NODE_EXTRA_CA_CERTS, and exposes a VP_INSECURE_TLS diagnostic opt-in. Routes every existing reqwest::get / Client::new site in vite_install and vite_js_runtime through it so vp can traverse TLS-intercepting tools like Socket Firewall Free (sfw) and corporate MITM proxies. Adds an install-e2e-test-sfw job (Linux/macOS/Windows) that downloads the upstream sfw binary and runs `sfw vp i -g pnpm@9.15.0` plus `sfw vp install` against vitejs/vite. Gated on the `test: sfw` label for PRs, unconditional on push-to-main. Carries VP_INSECURE_TLS=1 until sfw upstream ships the EKU fix (SocketDev/sfw-free#30, #43); flip removed once that lands to also exercise CA injection. Refs voidzero-dev/setup-vp#73
Verified locally with sfw 0.12.22: the CA cert sfw issues has no Extended Key Usage extension at all (Basic Constraints CA:TRUE + Key Usage critical Certificate Sign), which rustls and native-tls accept per RFC 5280. The original bug (SocketDev/sfw-free#30, #43) — a present-but-empty EKU that rustls rejected — appears to have been fixed upstream. Removing VP_INSECURE_TLS=1 lets this CI job exercise the full CA-injection path (SSL_CERT_FILE -> Certificate::from_pem -> add_root_certificate -> TLS handshake) end-to-end, not just the proxy plumbing. Local reproduction: $ cat /tmp/p/package.json { "name":"sfw-tls-test", "packageManager":"pnpm@9.15.0" } $ rm -rf ~/.vite-plus/package_manager/pnpm/9.15.0* $ unset VP_INSECURE_TLS $ sfw vp install --no-frozen-lockfile Protected by Socket Firewall === Socket Firewall === 1 packages fetched successfully $ ls ~/.vite-plus/package_manager/pnpm/9.15.0/ -> pnpm
Two regressions surfaced in the last CI run: 1. Linux failed with `Failed to download from nodejs.org` — sfw's GitHub release v1.10.0 still issues a CA with a present-but-empty Extended Key Usage, which rustls rejects. My local verification used `sfw` from npm (0.12.x, separate version track) which doesn't carry the bug; the GitHub releases (what CI downloads) do. Restore VP_INSECURE_TLS=1 on this step until SocketDev/sfw-free#30 / #43 are released. 2. Windows failed with `Command 'vp.cmd' not found in PATH`. vp on Windows ships as `vp.exe` (the trampoline), not `vp.cmd`. sfw's earlier "try vp.cmd" suggestion was a generic PATHEXT hint.
sfw v1.11.0 was published 2026-05-27, which may include the EKU fix referenced in SocketDev/sfw-free#30 / #43. Drop the bypass and let CI verify whether rustls (Linux/macOS) and native-tls (Windows) now accept sfw's CA. If any matrix entry fails with an UnknownIssuer-style TLS error, restore VP_INSECURE_TLS=1 with a fresh reference to the upstream issues.
The dropped-VP_INSECURE_TLS experiment confirmed via the now-readable error chain that sfw v1.11.0 (releases/latest as of 2026-05-28) still issues a CA cert with a present-but-empty Extended Key Usage: error sending request for url (https://nodejs.org/.../SHASUMS256.txt): client error (Connect): invalid peer certificate: UnknownIssuer (The new error-chain formatter from f105aa9 made the actual rustls reason visible — previously the same failure looked like a generic "error sending request" with no hint.) macOS happened to pass without the flag only because that runner had Node 22.18.0 already cached, so vp didn't have to fetch SHASUMS via sfw — not a real fix. Restore VP_INSECURE_TLS=1 on the sfw step (scoped to that step only to keep build/setup steps unaffected). The plumbing — HTTPS_PROXY + SSL_CERT_FILE + add_root_certificate — is still exercised end-to-end; only certificate *validity* is bypassed until SocketDev/sfw-free#30 and #43 ship.
Builds a single shared reqwest::Client in vite_shared that honors HTTPS_PROXY / HTTP_PROXY / NO_PROXY, loads PEM bundles from SSL_CERT_FILE and NODE_EXTRA_CA_CERTS, and exposes a VP_INSECURE_TLS diagnostic opt-in. Routes every existing reqwest::get / Client::new site in vite_install and vite_js_runtime through it so vp can traverse TLS-intercepting tools like Socket Firewall Free (sfw) and corporate MITM proxies. Adds an install-e2e-test-sfw job (Linux/macOS/Windows) that downloads the upstream sfw binary and runs `sfw vp i -g pnpm@9.15.0` plus `sfw vp install` against vitejs/vite. Gated on the `test: sfw` label for PRs, unconditional on push-to-main. Carries VP_INSECURE_TLS=1 until sfw upstream ships the EKU fix (SocketDev/sfw-free#30, #43); flip removed once that lands to also exercise CA injection. Refs voidzero-dev/setup-vp#73
Verified locally with sfw 0.12.22: the CA cert sfw issues has no Extended Key Usage extension at all (Basic Constraints CA:TRUE + Key Usage critical Certificate Sign), which rustls and native-tls accept per RFC 5280. The original bug (SocketDev/sfw-free#30, #43) — a present-but-empty EKU that rustls rejected — appears to have been fixed upstream. Removing VP_INSECURE_TLS=1 lets this CI job exercise the full CA-injection path (SSL_CERT_FILE -> Certificate::from_pem -> add_root_certificate -> TLS handshake) end-to-end, not just the proxy plumbing. Local reproduction: $ cat /tmp/p/package.json { "name":"sfw-tls-test", "packageManager":"pnpm@9.15.0" } $ rm -rf ~/.vite-plus/package_manager/pnpm/9.15.0* $ unset VP_INSECURE_TLS $ sfw vp install --no-frozen-lockfile Protected by Socket Firewall === Socket Firewall === 1 packages fetched successfully $ ls ~/.vite-plus/package_manager/pnpm/9.15.0/ -> pnpm
Two regressions surfaced in the last CI run: 1. Linux failed with `Failed to download from nodejs.org` — sfw's GitHub release v1.10.0 still issues a CA with a present-but-empty Extended Key Usage, which rustls rejects. My local verification used `sfw` from npm (0.12.x, separate version track) which doesn't carry the bug; the GitHub releases (what CI downloads) do. Restore VP_INSECURE_TLS=1 on this step until SocketDev/sfw-free#30 / #43 are released. 2. Windows failed with `Command 'vp.cmd' not found in PATH`. vp on Windows ships as `vp.exe` (the trampoline), not `vp.cmd`. sfw's earlier "try vp.cmd" suggestion was a generic PATHEXT hint.
sfw v1.11.0 was published 2026-05-27, which may include the EKU fix referenced in SocketDev/sfw-free#30 / #43. Drop the bypass and let CI verify whether rustls (Linux/macOS) and native-tls (Windows) now accept sfw's CA. If any matrix entry fails with an UnknownIssuer-style TLS error, restore VP_INSECURE_TLS=1 with a fresh reference to the upstream issues.
The dropped-VP_INSECURE_TLS experiment confirmed via the now-readable error chain that sfw v1.11.0 (releases/latest as of 2026-05-28) still issues a CA cert with a present-but-empty Extended Key Usage: error sending request for url (https://nodejs.org/.../SHASUMS256.txt): client error (Connect): invalid peer certificate: UnknownIssuer (The new error-chain formatter from f105aa9 made the actual rustls reason visible — previously the same failure looked like a generic "error sending request" with no hint.) macOS happened to pass without the flag only because that runner had Node 22.18.0 already cached, so vp didn't have to fetch SHASUMS via sfw — not a real fix. Restore VP_INSECURE_TLS=1 on the sfw step (scoped to that step only to keep build/setup steps unaffected). The plumbing — HTTPS_PROXY + SSL_CERT_FILE + add_root_certificate — is still exercised end-to-end; only certificate *validity* is bypassed until SocketDev/sfw-free#30 and #43 ship.
Builds a single shared reqwest::Client in vite_shared that honors HTTPS_PROXY / HTTP_PROXY / NO_PROXY, loads PEM bundles from SSL_CERT_FILE and NODE_EXTRA_CA_CERTS, and exposes a VP_INSECURE_TLS diagnostic opt-in. Routes every existing reqwest::get / Client::new site in vite_install and vite_js_runtime through it so vp can traverse TLS-intercepting tools like Socket Firewall Free (sfw) and corporate MITM proxies. Adds an install-e2e-test-sfw job (Linux/macOS/Windows) that downloads the upstream sfw binary and runs `sfw vp i -g pnpm@9.15.0` plus `sfw vp install` against vitejs/vite. Gated on the `test: sfw` label for PRs, unconditional on push-to-main. Carries VP_INSECURE_TLS=1 until sfw upstream ships the EKU fix (SocketDev/sfw-free#30, #43); flip removed once that lands to also exercise CA injection. Refs voidzero-dev/setup-vp#73
Verified locally with sfw 0.12.22: the CA cert sfw issues has no Extended Key Usage extension at all (Basic Constraints CA:TRUE + Key Usage critical Certificate Sign), which rustls and native-tls accept per RFC 5280. The original bug (SocketDev/sfw-free#30, #43) — a present-but-empty EKU that rustls rejected — appears to have been fixed upstream. Removing VP_INSECURE_TLS=1 lets this CI job exercise the full CA-injection path (SSL_CERT_FILE -> Certificate::from_pem -> add_root_certificate -> TLS handshake) end-to-end, not just the proxy plumbing. Local reproduction: $ cat /tmp/p/package.json { "name":"sfw-tls-test", "packageManager":"pnpm@9.15.0" } $ rm -rf ~/.vite-plus/package_manager/pnpm/9.15.0* $ unset VP_INSECURE_TLS $ sfw vp install --no-frozen-lockfile Protected by Socket Firewall === Socket Firewall === 1 packages fetched successfully $ ls ~/.vite-plus/package_manager/pnpm/9.15.0/ -> pnpm
Two regressions surfaced in the last CI run: 1. Linux failed with `Failed to download from nodejs.org` — sfw's GitHub release v1.10.0 still issues a CA with a present-but-empty Extended Key Usage, which rustls rejects. My local verification used `sfw` from npm (0.12.x, separate version track) which doesn't carry the bug; the GitHub releases (what CI downloads) do. Restore VP_INSECURE_TLS=1 on this step until SocketDev/sfw-free#30 / #43 are released. 2. Windows failed with `Command 'vp.cmd' not found in PATH`. vp on Windows ships as `vp.exe` (the trampoline), not `vp.cmd`. sfw's earlier "try vp.cmd" suggestion was a generic PATHEXT hint.
sfw v1.11.0 was published 2026-05-27, which may include the EKU fix referenced in SocketDev/sfw-free#30 / #43. Drop the bypass and let CI verify whether rustls (Linux/macOS) and native-tls (Windows) now accept sfw's CA. If any matrix entry fails with an UnknownIssuer-style TLS error, restore VP_INSECURE_TLS=1 with a fresh reference to the upstream issues.
The dropped-VP_INSECURE_TLS experiment confirmed via the now-readable error chain that sfw v1.11.0 (releases/latest as of 2026-05-28) still issues a CA cert with a present-but-empty Extended Key Usage: error sending request for url (https://nodejs.org/.../SHASUMS256.txt): client error (Connect): invalid peer certificate: UnknownIssuer (The new error-chain formatter from f105aa9 made the actual rustls reason visible — previously the same failure looked like a generic "error sending request" with no hint.) macOS happened to pass without the flag only because that runner had Node 22.18.0 already cached, so vp didn't have to fetch SHASUMS via sfw — not a real fix. Restore VP_INSECURE_TLS=1 on the sfw step (scoped to that step only to keep build/setup steps unaffected). The plumbing — HTTPS_PROXY + SSL_CERT_FILE + add_root_certificate — is still exercised end-to-end; only certificate *validity* is bypassed until SocketDev/sfw-free#30 and #43 ship.
Builds a single shared reqwest::Client in vite_shared that honors HTTPS_PROXY / HTTP_PROXY / NO_PROXY, loads PEM bundles from SSL_CERT_FILE and NODE_EXTRA_CA_CERTS, and exposes a VP_INSECURE_TLS diagnostic opt-in. Routes every existing reqwest::get / Client::new site in vite_install and vite_js_runtime through it so vp can traverse TLS-intercepting tools like Socket Firewall Free (sfw) and corporate MITM proxies. Adds an install-e2e-test-sfw job (Linux/macOS/Windows) that downloads the upstream sfw binary and runs `sfw vp i -g pnpm@9.15.0` plus `sfw vp install` against vitejs/vite. Gated on the `test: sfw` label for PRs, unconditional on push-to-main. Carries VP_INSECURE_TLS=1 until sfw upstream ships the EKU fix (SocketDev/sfw-free#30, #43); flip removed once that lands to also exercise CA injection. Refs voidzero-dev/setup-vp#73
Verified locally with sfw 0.12.22: the CA cert sfw issues has no Extended Key Usage extension at all (Basic Constraints CA:TRUE + Key Usage critical Certificate Sign), which rustls and native-tls accept per RFC 5280. The original bug (SocketDev/sfw-free#30, #43) — a present-but-empty EKU that rustls rejected — appears to have been fixed upstream. Removing VP_INSECURE_TLS=1 lets this CI job exercise the full CA-injection path (SSL_CERT_FILE -> Certificate::from_pem -> add_root_certificate -> TLS handshake) end-to-end, not just the proxy plumbing. Local reproduction: $ cat /tmp/p/package.json { "name":"sfw-tls-test", "packageManager":"pnpm@9.15.0" } $ rm -rf ~/.vite-plus/package_manager/pnpm/9.15.0* $ unset VP_INSECURE_TLS $ sfw vp install --no-frozen-lockfile Protected by Socket Firewall === Socket Firewall === 1 packages fetched successfully $ ls ~/.vite-plus/package_manager/pnpm/9.15.0/ -> pnpm
Two regressions surfaced in the last CI run: 1. Linux failed with `Failed to download from nodejs.org` — sfw's GitHub release v1.10.0 still issues a CA with a present-but-empty Extended Key Usage, which rustls rejects. My local verification used `sfw` from npm (0.12.x, separate version track) which doesn't carry the bug; the GitHub releases (what CI downloads) do. Restore VP_INSECURE_TLS=1 on this step until SocketDev/sfw-free#30 / #43 are released. 2. Windows failed with `Command 'vp.cmd' not found in PATH`. vp on Windows ships as `vp.exe` (the trampoline), not `vp.cmd`. sfw's earlier "try vp.cmd" suggestion was a generic PATHEXT hint.
sfw v1.11.0 was published 2026-05-27, which may include the EKU fix referenced in SocketDev/sfw-free#30 / #43. Drop the bypass and let CI verify whether rustls (Linux/macOS) and native-tls (Windows) now accept sfw's CA. If any matrix entry fails with an UnknownIssuer-style TLS error, restore VP_INSECURE_TLS=1 with a fresh reference to the upstream issues.
The dropped-VP_INSECURE_TLS experiment confirmed via the now-readable error chain that sfw v1.11.0 (releases/latest as of 2026-05-28) still issues a CA cert with a present-but-empty Extended Key Usage: error sending request for url (https://nodejs.org/.../SHASUMS256.txt): client error (Connect): invalid peer certificate: UnknownIssuer (The new error-chain formatter from f105aa9 made the actual rustls reason visible — previously the same failure looked like a generic "error sending request" with no hint.) macOS happened to pass without the flag only because that runner had Node 22.18.0 already cached, so vp didn't have to fetch SHASUMS via sfw — not a real fix. Restore VP_INSECURE_TLS=1 on the sfw step (scoped to that step only to keep build/setup steps unaffected). The plumbing — HTTPS_PROXY + SSL_CERT_FILE + add_root_certificate — is still exercised end-to-end; only certificate *validity* is bypassed until SocketDev/sfw-free#30 and #43 ship.
…1686) Track B of [voidzero-dev/setup-vp#73](voidzero-dev/setup-vp#73) — makes `vp` work through Socket Firewall Free (sfw) and other TLS-intercepting proxies. ## What - **New `vite_shared::shared_http_client()`**: process-wide `reqwest::Client` that honors `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY`, picks up macOS System Settings / Windows registry proxies (`system-proxy` feature), loads custom CAs from `SSL_CERT_FILE` and `NODE_EXTRA_CA_CERTS` (additive, Node-style), and has connect + request timeouts. `VP_INSECURE_TLS` (truthy only — `1`/`true`/`yes`/`on`) is a diagnostic escape hatch with a loud warning. - **All `reqwest::get` / `reqwest::Client::new()` call sites** in `vite_install` and `vite_js_runtime` routed through the shared client. - **`vite_shared::format_error_chain`**: walks `Error::source()` so users see `... invalid peer certificate: UnknownIssuer` instead of the opaque `error sending request for url`. Wired into both `Error::Reqwest` variants and the four `DownloadFailed { reason }` sites. - **New `install-e2e-test-sfw` CI job** (Linux / macOS / Windows): downloads upstream `sfw`, runs `sfw vp i -g pnpm@…` + `sfw vp install` against a fresh `vitejs/vite` clone. Gated on the `test: sfw` label for PRs; unconditional on push-to-main. `VP_INSECURE_TLS=1` is scoped to the Linux entry only (workaround for [SocketDev/sfw-free#30](SocketDev/sfw-free#30) / [#43](SocketDev/sfw-free#43) — present-but-empty EKU rejected by rustls). ## Out of scope / follow-ups - Switch to `rustls-native-certs` so OS-installed CAs work without env vars — Track B step 5, separate PR. - Drop `vp_insecure_tls` from the Linux matrix once SocketDev/sfw-free ships the EKU fix (one-line change). Refs voidzero-dev/setup-vp#73
close ENG-1180
🤖 Code with Claude Code