Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭 适合新手
  • 哪里不对？
#1,091 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 7 天内回复

@gangster 已经在做这个了。

开始于 2026年8月5日。

  • #1092 来自 @gangster —— 未关闭

评估

难度
1/5
预计耗时
1 小时以内
新手友好度
88/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
javascript
领域
cli

调研方向

从 app/config.js 中的 getDatabaseConfig 开始，尤其检查第 208-213 行附近的保护逻辑，并使用提供的 npm test --db=postgres 或直接的 Node 命令确认行为。验证未知名称（包括 toString）会产生预期的错误，而 sqlite、mysql、sqlite: 和默认值仍能正常解析。

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
JavaScript
星标
30
派生
26
平均合并
6 天 24 分钟
30 天内合并 PR
6

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

shift-org/shift-docs 的其他 Issue

查看 shift-org/shift-docs 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。