No-unsupported-api preflight can pass while the community catalog rejects the same plugin

Devs: Plugins & API
1

Environment

eslint-plugin-obsidianmd 0.4.2, ESLint 9.39.4, typescript-eslint latest, obsidian 1.13.x (obsidian.d.ts ships SettingTab.update() and SettingTab.settingItems as @since 1.13.0)

What happens

The plugin ships the recommended preflight and it is green, yet the submission catalog flags API usage: it resolves symbols through the TypeScript compiler and ignores eslint-disable directives, so two categories slip through no-unsupported-api:

  • a member call written as computed access (this["update"]()) is never reported, because the rule returns early on node.computed; the catalog resolves it and rejects
  • a locally suppressed line (// eslint-disable-next-line obsidianmd/no-unsupported-api) keeps the lint green, while the catalog rejects regardless of the directive

Expected

A green preflight with no-unsupported-api should be a faithful predictor of the catalog verdict, or the catalog’s stricter resolution and its inability to honor directives should be documented as part of the preflight contract

Minimal repro (plugin with minAppVersion: 1.7.2)

// API is @since 1.13.0 on SettingTab
this.update();            // reported: "SettingTab.update requires v1.13.0"
// eslint-disable-next-line obsidianmd/no-unsupported-api
this.update();            // not reported (directive honored)
this["update"]?.();       // not reported (computed access skipped)

Note

Direct member calls are caught correctly (tested this.update(), super.update(), this.settingItems). The gap is coverage of computed access and of suppression, not of ordinary member resolution

1 Like