Unknown --db values report a TypeError instead of the intended error

[gangster]

getDatabaseConfig means to reject an unrecognised database type with a clear message, but the guard is written as !name in config. Operator precedence makes that (!name) in config, so it tests whether the boolean false is a key of the config object. It never is, so the throw is unreachable for every possible input.

Instead of the intended message, an unknown type dies two lines later with an internal type error pointing at the wrong line.

Reproducing

$ npm test --db=postgres
TypeError: config[name] is not a function
npm error code 7

Or directly:

$ npm_config_db=postgres node -e "require('./app/config.js')"
TypeError: config[name] is not a function
    at getDatabaseConfig (app/config.js:213:26)

Expected: unknown database type 'postgres' from line 208.

The precedence is easy to confirm in isolation:

name              : "postgres"
!name             : false
!name in config   : false     <-- what is evaluated: (false in config)
!(name in config) : true      <-- what was meant

Because !name is false for any non-empty string, the guard never fires — not for postgres, not for banana, not for anything.

A second problem with the obvious fix

The minimal correction is !(name in config), but in walks the prototype chain and config is a plain object literal, so inherited keys would still slip through:

$ npm_config_db=toString node -e "require('./app/config.js')"
no error. db config = {"type":"toString","connect":"[object Object]","debug":false}

config.toString(parts) returns the string "[object Object]", which is then handed on as the connection settings and fails somewhere less obvious in db.js.

This needs someone to type --db=toString, so it is a curiosity rather than a risk. But it is the same class of bug as #1089, and the own-property form is no longer to write.

Suggested fix

-  if (!name in config) {
+  if (!Object.hasOwn(config, name)) {
     throw new Error(`unknown database type '${dbType}'`)
   }

With that, every unrecognised type — including toString and constructor — produces Error: unknown database type '<name>', and sqlite, mysql, sqlite:<path> and the no-argument default all continue to resolve as before.

Severity

Low, and developer-facing only: it costs a contributor a few minutes chasing a misleading stack trace after a typo in --db. Filing it because the fix is one line and the diagnosis is not obvious from the symptom.