knex in monorepo can't find sqlite3 installation.

[codelocksdev]

Environment

Knex version: 2.4.2
Database + version: sqlite3@5.1.4
OS: Windows 10 and Mac Ventura 13.1

Bug

1. Explain what kind of behaviour you are getting and how you think it should do

I have an @nrwl/nx setup and I have my knex code set up in a library file that is then being imported in my backend node app, with some simple test insertion and then printing the query to the console per the objectionjs getting started docs.

When I build the node app, everything compiles and runs, until the knex: run background process happens at which point I get error output that looks like it's trying to npm install sqlite3, which I already have installed at the root of my monorepo project. The error is indicating to me that the CWD is not what knex is expecting, so it's #1 not finding my node_modules and therefore not finding my sqlite3 installation, and #2 it's calling npm install in a directory that doesn't have a package.json and so that's failing too.

2. Error message

> nx run backend:serve

[ watch ] build succeeded, watching for changes...
Debugger listening on ws://localhost:9229/fa3267c7-c2c9-4312-8cd3-5c675c1c0c19
Debugger listening on ws://localhost:9229/fa3267c7-c2c9-4312-8cd3-5c675c1c0c19
For help, see: https://nodejs.org/en/docs/inspector
Knex: run
$ npm install sqlite3 --save
/Users/codelocksdev/Documents/dev/repos/gedmap/dist/apps/package.jsondoes not exist
Error: /Users/codelocksdev/Documents/dev/repos/gedmap/dist/apps/package.jsondoes not exist
    at Object.exports.find (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/@mapbox/node-pre-gyp/lib/pre-binding.js:19:11)
    at node_modules/sqlite3/lib/sqlite3-binding.js (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/sqlite3/lib/sqlite3-binding.js:3:29)
    at __require (/Users/codelocksdev/Documents/dev/repos/gedmap/dist/apps/backend/main.js:8:50)
    at node_modules/sqlite3/lib/sqlite3.js (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/sqlite3/lib/sqlite3.js:2:17)
    at __require (/Users/codelocksdev/Documents/dev/repos/gedmap/dist/apps/backend/main.js:8:50)
    at Client_SQLite3._driver (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/dialects/sqlite3/index.js:42:12)
    at Client_SQLite3.initializeDriver (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/client.js:190:26)
    at new Client (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/client.js:75:12)
    at new Client_SQLite3 (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/dialects/sqlite3/index.js:22:5)
    at knex2 (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/knex-builder/Knex.js:16:28)

/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/client.js:194
      throw new Error(`${message}\n${e.message}`);
            ^
Error: Knex: run
$ npm install sqlite3 --save
/Users/codelocksdev/Documents/dev/repos/gedmap/dist/apps/package.jsondoes not exist
    at Client_SQLite3.initializeDriver (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/client.js:194:13)
    at new Client (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/client.js:75:12)
    at new Client_SQLite3 (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/dialects/sqlite3/index.js:22:5)
    at Knex (/Users/codelocksdev/Documents/dev/repos/gedmap/node_modules/knex/lib/knex-builder/Knex.js:16:28)
    at Object.<anonymous> (/Users/codelocksdev/Documents/dev/repos/gedmap/libs/db/src/config/knex.ts:3:14)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Function.Module._load (/Users/codelocksdev/Documents/dev/repos/gedmap/packages/js/src/executors/node/node-with-require-overrides.ts:16:27)

While this bug seems to be caused by the combination of knex and an integrated monorepo project structure, I think the root of the problem seems to be happening in the knex logic.

Is this configurable or does it need a bug fix?