For me this whole gyp ERR! started appearing on just about every other repo I work with when I updated node to v18 (as far as I can remember) and tried to install deps (not just parcel too). Sure enough, downgrading to v16 resolved the entire problem. I am on Windows 10. Writing this possible “fix” here for anyone not yet wanting to upgrade deps for some reason.

got the same error after upgrading Node to v18 ( everything is working properly if I switch node version back to v16 )

I had this issue on M1 MacBook Pro. npm install -D parcel --ignore-scripts resolved the issue.

The lmdb package definitely has precompiled binaries for these OS/architectures and so you should not be needing to locally compiling binaries with python, MSVS, gcc, or anything else. If these are not present, it seems like it may be an issue with the installation not working right, an incompatible package override, or the binaries being deleted or somehow corrupted.

I would check to make sure your binaries have been properly installed by NPM first. @rincewindcz, your binary should be at /tmp/parcel-bug/node_modules/lmdb-linux-x64/node.abi108.node (from lmdb-linux-x64). @mixaildudin , you binary should be at C:\Users\asdf\Documents\react-app\node_modules\lmdb-win32-x64\node.abi93.node (from lmdb-win32-x64). (If anyone else wants to know the specific location to check, let me know).

If the binary is there, the next thing I would try is to force the npm install to not using any locally compilation by using --ignore-scripts and/or making sure that node_modules/lmdb/build folder is deleted/gone and then try loading lmdb with `node -e “console.log(require(‘lmdb’))”. If there is some binary corruption or CPU incompatibility issue at the OS level, this should report it.

One other thing to check is to make sure that there was no weird package version override and that the correct versions are with npm ls lmdb node-gyp-build-optional-packages, which should have lmdb@2.3.10 and node-gyp-build-optional-packages@4.3.2. If either of those are wrong, naturally that would cause problems.

Hopefully that helps isolate the issue, certainly let me know if you have any questions.

Yet another +1 that downgrading to node v16 (from v19 for me) was a successful (temporary?) fix for me.

@srishilesh msgpackr-extract is not a (required) dependency of gatsby. Or parcel. Or lmdb-js. Or msgpackr. So if you have not explicitly added msgpackr-extract as a dependency in your package.json, this should just be logging noise, not a real failure. Also, this is because node.js v10 is not a supported version of node (according to node.js themselves, and generally unsafe to use due to a lack of security patches).

Ok, trying again with 4.3.5, hopefully the carriage returns are gone now.

@srishilesh msgpackr-extract is not a (required) dependency of gatsby. Or parcel. Or lmdb-js. Or msgpackr. So if you have not explicitly added msgpackr-extract as a dependency in your package.json, this should just be logging noise, not a real failure. Also, this is because node.js v10 is not a supported version of node (according to node.js themselves, and generally unsafe to use due to a lack of security patches).

Thanks for the help. Noted.

Ok, I published an updated node-gyp-build-optional-packages (patch version, should be semver compatible and automatically used). Hopefully this should fix this issue. I can’t reproduce this issue, so I can’t verify it, but at least nothing seems broken from my testing.

NPM will rollback failed installation, so --ignore-scripts is required to see package content in the first place.

node-gyp-build-optional-packages script invokes node-gyp-build-test, but node-gyp-build package (required by @parcel/watcher@2.0.5) also provides a node-gyp-build-test script, so the prebuilt binary was not detected.

node_modules/.bin/node-gyp-build-test:

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*|*MINGW*|*MSYS*) basedir=`cygpath -w "$basedir"`;;
esac

if [ -x "$basedir/node" ]; then
  exec "$basedir/node"  "$basedir/../node-gyp-build/build-test.js" "$@"
else 
  exec node  "$basedir/../node-gyp-build/build-test.js" "$@"
fi

$ npm ls node-gyp-build
test@1.0.0 <redacted>/test
└─┬ parcel@2.6.0
  └─┬ @parcel/fs@2.6.0
    └─┬ @parcel/watcher@2.0.5
      └── node-gyp-build@4.4.0

run npm install --verbose parcel:

npm ERR! code 1
npm ERR! path <redacted>\node_modules\lmdb
npm ERR! command failed
npm ERR! command C:\WINDOWS\system32\cmd.exe /d /s /c node-gyp-build-optional-packages
npm ERR! <redacted>\node_modules\node-gyp-build\index.js:60
npm ERR!   throw new Error('No native build was found for ' + target + '\n    loaded from: ' + dir + '\n')
npm ERR!   ^
npm ERR!
npm ERR! Error: No native build was found for platform=win32 arch=x64 runtime=node abi=93 uv=1 libc=glibc node=16.13.1
npm ERR!     loaded from: <redacted>\node_modules\lmdb
npm ERR!
npm ERR!     at Function.load.path (<redacted>\node_modules\node-gyp-build\index.js:60:9)
npm ERR!     at load (<redacted>\node_modules\node-gyp-build\index.js:22:30)
npm ERR!     at Object.<anonymous> (<redacted>\node_modules\node-gyp-build\build-test.js:19:19)
npm ERR!     at Module._compile (node:internal/modules/cjs/loader:1101:14)
npm ERR!     at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
npm ERR!     at Module.load (node:internal/modules/cjs/loader:981:32)
npm ERR!     at Function.Module._load (node:internal/modules/cjs/loader:822:12)
npm ERR!     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
npm ERR!     at node:internal/main/run_main_module:17:47

Notice the stacktrace is fromnode-gyp-build package.

PS. so funny that it only recognizes npm install --verbose, but not npm install -ddd

Okay, I resolved my issue. I already had VS 2022 Community installed, so I ran the VS installer, checked Node.js tools (and also checked C++ tools for Node.js or something like this), it downloaded 3Gb of data from the internet, now parcel@2.6.0 installs smoothly.

But this is still lame. Looks like someone forgot to include their pre-compiled binaries into the package or something.

Cannot install the new parcel on two machines with Win10, tried with Node 14.16.0, 14.16.1 and 16.15.0.

On one machine npm says it cannot find Python. On the other one it says it cannot find MSVS, and all because of node-gyp and lmdb. Meanwhile, parcel@2.5.0 works ok.

I hope 2.5.0 is not the last version to work on both of my computers. Cause it would be really uncomfortable to install Python, install MSVS and all the necessary build tools for Parcel which used to work like a charm just several days ago, and the main advantage of Parcel is that it’s supposed to work just out of the box!