WSL2 BUILDS OF THE CONTINUE VS CODE EXTENSION SHIP LINUX BINARIES, BREAK ON WINDOWS
Building the Continue VS Code extension (VSIX) from WSL2 packages Linux-native binaries (sqlite3, LanceDB, ripgrep), and the extension fails to activate on Wind...
Building the Continue VS Code extension (VSIX) from WSL2 packages Linux-native binaries (sqlite3, LanceDB, ripgrep), and the extension fails to activate on Windows with "not a valid Win32 application." The prepack step targets the current platform; trying a win32 target from Linux fails due to missing Windows artifacts (e.g., rg.exe), indicating the need for cross-target packaging or universal bundles.
Many devs and CI build on Linux while running VS Code on Windows, so mismatched native modules can silently break AI tooling and slow iteration.
Robust cross-target builds improve reproducibility for any extension or Node project with native dependencies.
-
terminal
Add CI to package VSIX for win32-x64 from Linux and run activation smoke tests on a Windows runner to verify native module loading.
-
terminal
Validate packaging fetches the correct platform binaries for sqlite3/LanceDB/ripgrep and fails fast if artifacts are missing.
Legacy codebase integration strategies...
- 01.
Update build scripts to download platform-specific prebuilt binaries during cross-target packaging and document WSL2 build constraints.
- 02.
As a stopgap, require marketplace installs or native Windows builds for local VSIX testing from WSL2.
Fresh architecture paradigms...
- 01.
Prefer dependencies with cross-platform prebuilds or WASM to avoid .node binaries in the extension host.
- 02.
Set up a multi-target release matrix (win32, linux, arm64) with activation tests in Windows, WSL Remote, and Linux.