Shipping Native Node Modules to Users Who Don't Have a Compiler

Native Node addons, things like better-sqlite3 or node-pty, need a compiled binary matched to the exact platform and Node ABI they'll run on. Building that binary from source requires a C compiler toolchain. Most non-developer end users don't have one installed, and won't want to install Xcode Command Line Tools or Visual Studio Build Tools just to run your app. The fix that actually works in production: default to a precompiled-binary download rather than a source build. Most native packages already bundle prebuild-install support for exactly this, use it to fetch a binary matched to the user's Node ABI automatically. Fall back to a real source build (`node-gyp rebuild`) only when a compiler is actually detected on the machine. And critically, don't trust a successful download or a zero exit code as proof the module works, end with an actual `require()` smoke test that loads the binary for real. That last step matters more than it sounds like it should. On macOS specifically, a freshly downloaded `.node` file carries a Gatekeeper quarantine extended attribute that silently blocks it from loading even after a completely successful download. The fix is an explicit `xattr -d` strip on the downloaded artifact before the load test runs. Skip that step and your installer will report success on a binary that can't actually be loaded. If you're shipping any CLI or desktop app with native dependencies to non-developer users, this exact sequence, precompiled-first, compiler-gated source fallback, load smoke test, quarantine strip on macOS, is close to the minimum bar for a reliable install.