按需启用扩展包
核心的 ApiPage / ApiQueryResult 只覆盖 MediaWiki 核心的字段,扩展引入的字段类型按扩展拆成按需启用的包(子路径 types-mediawiki-response/ext/<name>),对照站点实际安装的扩展激活即可。
使用上分两种场景,机制不同:
- 已装扩展的 query 模块字段(响应里多出来的某个
list=/prop=/meta=键):每个项目激活一次,之后这些字段直接出现在所有文件的ApiPage/ApiQueryResult上。 - 扩展的 action(
action=shortenurl、action=thank等):像核心 action 一样,在需要的地方按名导入独立的响应类型。
场景一:已装扩展的 query 字段
每个包自带 declare module 增广——键名与落点收在包内,消费方项目里不会冻结一段日后会漂移的片段。激活一个包只需从它 type-only 导入任意内容:
推荐放一个专门的类型文件(例如 mw-response.d.ts,保持在 tsconfig 的 include 字段内),在文件内列全当前项目对应 wiki 实际安装的扩展。增广对整个 tsconfig 所覆盖的项目生效,业务文件不用重复声明,可以直接用 page.flagged / query.notifications。或者只要在任意地方导入过要用的字段组类型(如 ApiPageFlagged),包的增广同样随之生效。
场景二:调用扩展的 action
扩展提供的 action 导出对应的独立响应类型,不并入 ApiPage / ApiQueryResult。从对应包按名导入,与核心 action 使用方法相同:
这一条 import 附带两件事:
- 该扩展如果还有 query 模块(比如
discussiontools既有action=discussiontoolspageinfo响应、又有prop=threaditemshtml),其 query 字段也随之激活。 - 仅为调用 action 时不需要把包写进
mw-response.d.ts;只有同时消费它的 query 字段才需要。
增广 query 类型的包
wiki 装了对应扩展就激活(场景一),所列模块的字段会出现在 ApiPage / ApiQueryResult 上:
引入新 action 的包
这些包导出独立的响应类型(场景二),根据调用的 action 导入对应类型:
同时出现在两张表里的包(如 abusefilters、discussiontools、flaggedrevs)两种场景都服务——激活一次,action 类型按需按名导入。
给包未覆盖的字段补充类型
同样的接缝是通用的。字段可能来自本包未建包的扩展,也可能来自站点 fork 给核心模块结果加的字段。自己声明形状,在对应的落点用模块增广并入;与内置包一样,增广对整个项目生效。
- 页面级
prop=字段并入ApiPage;其余 query 结果并入ApiQueryResult。 - 行接口——列表结果里的逐条目对象(
list=users的ApiUser、list=recentchanges的ApiRecentChange等)——站点在条目上加字段时,直接增广行接口本身。 - 日志明细的并入点是 ApiLogEventParams,自定义的 log action、以及仍留在老行里的遗留键形都从这里并入。
- 开放联合的已知值(如站点注册的内容模型)通过联合的提成接口并入,如
ContentModelExtension——开放与封闭的区分和增广示例见字段约定。 - action 响应是独立信封,没有可并入的共享形状,未覆盖来源的新 action 只需自己定义普通接口并按名导入。
把文件放在 tsconfig include 内即可,与内置包一样,增广对整个项目生效。
列表条目上的站点自定义字段,增广到行接口本身:
新的 action 则不需要增广,自己声明一个 extends ApiEnvelope 的响应接口,在调用该 action 的地方导入使用: