Skip to content

Untangle ChoiceView's circular imports so settings views are CI-testable #1249

@chhoumann

Description

@chhoumann

Context

During the Svelte 5 rewrite (#1248), ChoiceView.svelte could not be mounted in a vitest component test — its import graph has circular dependencies that the esbuild production bundle tolerates but vitest's ESM evaluation order does not, throwing Class extends value undefined:

  • ChoiceView → services/choiceService → quickAddApi → VDateInputPrompt ↔ GenericInputPrompt
  • … → formatters/completeFormatter → engines (e.g. SingleInlineScriptEngine extends MacroChoiceEngine)

As a result, ChoiceView's save/persistence flow is currently only verified by a local obsidian-e2e GUI test (tests/e2e/conditional-branch-persistence.test.ts), which can't run in CI (no Obsidian on the runner).

Goal

Untangle the cycles (likely by splitting the prompt/engine base classes out of the modules that re-import their subclasses, or deferring imports) so ChoiceView (and the other settings views) can be rendered in a vitest component test.

Acceptance

  • A vitest component test can render(ChoiceView, …) without Class extends value undefined.
  • The conditional Then/Else persistence flow gets a CI-runnable component/integration test (complementing the local e2e one).

Deferred from #1248 to keep that PR a behavior-preserving migration.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions