Fix: bigint Failed to load bindings, pure JS will be used

This line comes from the npm package bigint-buffer. It has a small native C++ part that npm is supposed to compile when you install it. When that compiled file is missing, the package prints this warning the moment it’s loaded and switches to plain JavaScript:

bigint: Failed to load bindings, pure JS will be used (try npm run rebuild?)

You usually didn’t install bigint-buffer yourself. In my test it came in through Solana’s token library:

`-- @solana/spl-token@0.4.15
  `-- @solana/buffer-layout-utils@0.3.0
    `-- bigint-buffer@1.1.5

require("@solana/spl-token") printed the warning and then loaded normally.

Is it a problem?

For most projects, no. It’s a warning, not an error, and the JavaScript version gives the same results. toBigIntLE on the same four bytes returned 67305985 both ways.

The only cost is speed. On Linux, a million conversions of a 32-byte buffer took 93 ms with the native build and 367 ms without it on Node 24 (91 and 474 ms on Node 26). That’s about four times slower, but still well under a microsecond per call. Unless you convert millions of values in a hot loop, you won’t notice.

Why you see it: three ways the native build goes missing

bigint-buffer’s install script runs node-gyp rebuild, and if that fails it prints Couldn't build bindings. Non-native version used. and carries on. I tried every combination below in a fresh folder.

1. npm 12 doesn’t run the install script

This is the new one. npm 12 blocks install scripts unless you approve them, so the native part is never built, even on a machine with every compiler installed. It says so during the install, and it’s easy to scroll past:

npm warn install-scripts 1 package had install scripts blocked because they are not covered by allowScripts:
npm warn install-scripts   bigint-buffer@1.1.5 (install: npm run rebuild || echo "Couldn't build bindings. Non-native version used.")

npm 11.19 and 11.20 print a similar notice (“has install scripts not yet covered by allowScripts”) but still run the script. In the node:24 and node:26 images, npm 11 built the native part and npm 12 didn’t.

npm install-scripts approve bigint-buffer
npm rebuild bigint-buffer

2. Windows without the C++ build tools

On Windows, npm 11 ran the script, and node-gyp couldn’t find a compiler:

gyp ERR! find VS could not use PowerShell to find Visual Studio 2017 or newer

Approving the script on npm 12 gives the same result. node-gyp needs the Visual C++ build tools, the same download that fixes the Python version of this error; I didn’t install them for this test, so I can’t confirm the rebuild after that. If speed doesn’t matter to you, it’s fine to leave the warning.

3. Slim Docker images

node:24-slim has no Python or C++ compiler, so node-gyp stopped at gyp ERR! find Python. The full node:24 image has both, and it built the native part (with the script approved on npm 12), so install your dependencies in a stage based on it.

The npm audit warning that comes with it

The same package shows up in npm audit:

bigint-buffer  *
Severity: high
bigint-buffer Vulnerable to Buffer Overflow via toBigIntLE() Function - https://github.com/advisories/GHSA-3gc7-fjrx-p6mg
fix available via `npm audit fix --force`
Will install @solana/spl-token@0.1.8, which is a breaking change

The advisory is CVE-2025-3194: every version up to 1.1.5, the latest, is affected, and there’s no patched release. The “fix” npm offers is a downgrade of @solana/spl-token from 0.4.15 to 0.1.8, which is a major step backwards in API. Don’t run npm audit fix --force for this one without reading what it will change. Whether the native build is present doesn’t change what the audit reports.

What didn’t work

How this was tested

October 31, 2026. Each case started from an empty folder with npm install bigint-buffer@1.1.5, then loaded it and checked whether its build/Release folder existed. Windows 11 Pro with Node 24.14.0 and npm 11.9.0, and npm 12.2.1 through npx; Linux in the official node:24, node:24-slim and node:26 images on GitHub Actions. The dependency chain came from installing @solana/spl-token. The speed test converted the same 32-byte buffer a million times with the module and with the same JavaScript code the module falls back to. The script and the full output are public.