@lark-project/cli/lib/utils/preflight-local-config.d.ts

飞书项目插件开发工具

/**
 * Pre-build / pre-start gate: validate `point.config.local.json` against
 * the plugin schema before any expensive work (webpack compile, dev server
 * bootstrap, remote upload) starts.
 *
 * Why here, given `local-config set` already validates: that gate only fires
 * when the config flows through the proper plan→set workflow. When AI (or a
 * developer) directly edits `point.config.local.json` and runs `lpm start`/
 * `lpm build`/`lpm release`, the schema check is skipped — webpack happily
 * compiles, the dev page boots, and the broken schema only surfaces when
 * release pushes to backend (or worse, silently produces a broken plugin).
 *
 * Gated purely on file existence: if `point.config.local.json` is in the
 * project, treat it as authoritative for local-mode runs and validate it.
 * `source_type` lives in `plugin.config.json` and is not a reliable trigger —
 * the CLI flag isn't always passed, and the file's mere presence already
 * signals intent to use local config.
 *
 * Why we write directly to process.stderr instead of going through `logger`:
 * the project's log4js console appender caches `process.stdout.write` /
 * `process.stderr.write` references at first flush, so test harnesses that
 * temporarily replace those writes (jest `IOCapture`) can't reliably observe
 * logger output. Preflight diagnostics are agent-readable error lists, so
 * stderr-direct keeps them deterministically capturable in tests + still
 * lands them on the correct sink for humans/CI.
 *
 * Exits the process with code 1 on validation errors so build/start fail fast
 * with a clear AI/developer-facing error list.
 */
export declare function preflightLocalConfig(): Promise<void>;