Diego Rodrigues de Sa e Souza b43a212680 fix(cliproxy): read os.platform()/os.arch() at runtime in binaryManager platform detection (#10244) (#10474) ...

* fix(cliproxy): read os.platform()/os.arch() at runtime in binaryManager platform detection (#10244)

detectPlatform()/detectArch() read the module's process.platform/process.arch,
which Turbopack `next build` (run only on Linux) constant-folds, pruning every
Windows/arm64 branch from the published npm artifact — so the embedded CLIProxyAPI
installer downloads the Linux ELF binary on Windows. Switch to runtime os.platform()/
os.arch() calls (the repo's established anti-fold pattern) so the Windows/ARM branches
survive any build machine. Add a regression guard mocking os.platform()/os.arch() to
win32/arm64 asserting the Windows/ARM path is reachable — RED before, GREEN after.

* fix(cliproxy): use runtime platform for binary install paths

Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>

* fix(cliproxy): thread runtime platform as a parameter instead of re-reading os.platform()

extractZip(), installVersion(), and rollbackVersion() each independently called
os.platform() inline in their own module scope even after #10244 switched the
detection helpers to os.platform()/os.arch(). Each independent call site is its
own opportunity for a bundler to constant-fold that particular occurrence away.

Detect the runtime platform once per orchestrating call (installVersion,
downloadRelease, rollbackVersion) and thread the already-detected value down as
an explicit parameter into extractZip and the symlink/copy decisions, instead of
re-reading the global in every helper.

---------

Co-authored-by: adevwithpurpose <adevwithpurpose@users.noreply.github.com>

2026-08-18 11:42:47 -03:00

14 KiB

Raw Blame History

View Raw