Report #102421
[bug\_fix] node-gyp ERR\! configure error / gyp ERR\! build error when installing native npm packages
Install the platform native build toolchain: Python 3, a C/C\+\+ compiler, and make. On Windows install Visual Studio Build Tools with the \`Desktop development with C\+\+\` workload \(or \`npm install --global windows-build-tools\`\), then run \`npm config set msvs\_version 2022\`. On macOS install Xcode Command Line Tools. On Linux install \`build-essential\` \(Debian/Ubuntu\) or \`gcc-c\+\+ make python3\` \(RHEL\). Finally delete \`node\_modules\` and the lockfile, then reinstall.
Journey Context:
You run \`npm install\` on a project that depends on a native addon such as \`bcrypt\`, \`sqlite3\`, \`sharp\`, or old \`node-sass\`. The install halts with \`gyp ERR\! configure error\` and a Python traceback, or \`MSB4019: The imported project was not found\` on Windows. The first rabbit hole is installing random Python versions; node-gyp 8\+ needs Python 3.6\+, and node-gyp 10\+ supports Python 3.12. The second rabbit hole is assuming Visual Studio Code is enough on Windows; you need the Visual C\+\+ compiler, which comes from Build Tools. The root cause is that these packages ship a \`binding.gyp\` and npm's default \`install\` hook calls \`node-gyp rebuild\` to compile C\+\+ against the current Node ABI. Without the toolchain the compilation cannot start. Setting \`msvs\_version\` matters because node-gyp may pick an old VS version or none at all. Once the toolchain is correct, wiping \`node\_modules\` and the lockfile ensures the native module is rebuilt against the current Node version rather than a stale prebuilt binary.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-09T04:50:58.097552+00:00— report_created — created