I'm using Rosetta 2 with Homebrew and have sqlite3 installed.

I added these to my ~/.zshrc so that the node compiler can find the brew installs:

export PATH="/usr/local/opt/sqlite/bin:$PATH"
export LDFLAGS="-L/usr/local/opt/sqlite/lib"
export CPPFLAGS="-I/usr/local/opt/sqlite/include"

I'm using installing using npm install sqlite3, building from source with --build-from-source flag, I'm also specifying the homebrew version of sqlite with --sqlite=/usr/local/opt/sqlite/

node-gyp goes to its fallback build node-pre-gyp install --fallback-to-build

After installation, I'm rebuilding it's native dependencies with electron-builder and install-app-deps

It even rebuilds to the platform and arch I'm looking for, darwin and x64. Which is promising.

  • electron-builder  version=23.0.3
  • loaded parent configuration  preset=react-cra
  • rebuilding native dependencies  [email protected] platform=darwin arch=x64

However, when run the app with npm run dev which runs concurrently " cross-env BROWSER=none npm start" "wait-on http://localhost:3000 && electron ."

It still is trying to find the arm64 version of it:

Error: Cannot find module '[..]/node_modules/sqlite3/lib/binding/napi-v6-darwin-unknown-arm64/node_sqlite3.node'

Even though I can confirm, it did build the x64 version because I have one located at: /napi-v6-darwin-unknown-x64/node_sqlite3.node

Any help to get this working would be greatly appreciated, thanks!

CodePudding user response：

After 4 days of digging, I have finally gotten it to work!!!

For anyone that might stumble on this:

The reason why sqlite3 won't behave is threefold:

1. When node sqlite3 is installed using npm install sqlite3, it fetches all dependencies and installs it. It then fetches the precompiled binary binding file for the target arch and platform. In my case we would want napi-v6-darwin-unknown-arm64 for ARM64 and darwin for Apple M1. There is no precompiled binary available yet for this Apple ARM64 and even if there is, the next paragraph will detail why it still won't work.

2. The problem is that it determines the the system's platform and architecture using the binary compiling package node-pre-gyp and this very savior of a Github issue details how node-pre-gyp is not handling ARM architecture detection properly and basically mixing everything up. Because it's not detecting properly, even if we build our own binding with --build-from-source when installing, it still won't work because it is compiling the wrong binding file for the wrong architecture. To make matters worse, if we don't use --build-from-source, it just simply fetches the Intel precompiled binding file. napi-v6-darwin-unknown-x64

3. Now for some reason, during runtime, it now detects the architecture properly and tries to look for the ARM64 version of the binding file, it won't find it and will throw the feared error 'module not found' for napi-v6-darwin-unknown-arm64. It obviously won't find it and even if it does, it will throw wrong architecture error because we have the Intel version on board napi-v6-darwin-unknown-x64.

So finally after digging at this for 4 days, here's how I got it working:

1. Uninstall sqlite3: npm uninstall sqlite3
2. Install a fresh sqlite3, build it from source, specify the target arch and use fallback build with node-pre-gyp just to be safe: npm install sqlite3 --build-from-source --target_arch=arm64 --fallback-to-build
3. Now the correct binding file is compiled for the correct platform and architecture, on runtime it will find it and will run!