TL;DR — Replaces the repeated [plugin.config['~hooks']?.X, plugin.context.config.parser.hooks.X] pattern with a single plugin.getHooks(selector, ...customHooks) helper, then threads it through every processor and the symbol resolver. Net effect is less boilerplate without behavioral change.

Key changes

• Add getHooks to PluginInstance — single entry point that returns a filtered array of [...customHooks, local, global] hooks, dropping undefined entries.
• Migrate schema extractors — pydantic/v2, @hey-api/typescript/v1, valibot/v1, zod/{mini,v3,v4} all swap their hand-rolled hook arrays for plugin.getHooks((hooks) => hooks.schemas?.shouldExtract).
• Migrate symbol resolvers — getSymbolExportFromFilePath, getSymbolFilePath, and buildSymbolIn now use getHooks and drop their inline null-guard loop.
• Simplify boolean-or-call branch — hook?.(ctx) ?? false becomes hook(ctx) since getHooks already filters undefined; downstream if (result) truthiness still folds boolean false and undefined together.

_{Summary ｜ 9 files ｜ 1 commit ｜ base: main ← refactor/plugin-hooks-order}

Centralized hook resolution

Before: every processor inlined [plugin.config['~hooks']?.schemas?.shouldExtract, plugin.context.config.parser.hooks.schemas?.shouldExtract] and each loop guarded hook?.(ctx) ?? false.
After: plugin.getHooks((hooks) => hooks.schemas?.shouldExtract) returns the filtered, ordered array; pydantic additionally passes its two built-in extractor predicates as varargs so they're prepended ahead of user hooks.

Ordering is [customHooks…, local (config['~hooks']), global (parser.hooks)], which matches every call site's previous order — pydantic kept its built-in object/enum predicates first, and every other processor's [local, global] ordering is preserved. The boolean-vs-function dispatch inside each extractor loop is unchanged.

instance.ts · symbol.ts · pydantic/v2/processor.ts

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}