Enhancement: index inner declarations of factory/setup callbacks — Vue Pinia setup stores, composables & React hooks (the Vue/React twin of the tracked Zustand gap)

[janmajorczyk]

Related, already-acknowledged gap: #392 lists "Zustand factory object-literal methods not extracted" under tracked feature gaps. This is the same root cause across the rest of the modern frontend world — Vue and React — and isn't tracked yet.

Why this is high-leverage

• It's the dominant pattern, not an edge case. Vue 3's Composition API (Pinia setup stores + composables) and React Hooks are the default way modern apps are written. In these files, the factory/setup callback is where essentially all the logic lives — actions, getters, effects, handlers.
• Today the graph indexes the shell and misses the substance. For a Pinia store, only useXStore becomes a node; every action/getter/helper inside is invisible.
• It directly undercuts the core value prop. The whole pitch is giving agents real structure so they don't fall back to full-file reads (the "120× token reduction"). But for any store/hook-heavy file, agents are forced back to grep/Read precisely because the symbols aren't in the graph — exactly where the tool should shine.
• One pass, two of the largest ecosystems. The same factory/setup-callback extraction unlocks Vue (Pinia + composables), React (hooks), and the Zustand gap you already track — broad framework appeal for a single, contained change.

Problem

search_graph models only top-level/exported declarations. Functions/consts declared inside a factory or setup callback aren't extracted.

// Vue + Pinia setup store
export const useFooStore = defineStore('foo', () => {
  const items = ref([])
  function selectFailed() { /* … */ }   // inner action — NOT indexed
  return { items, selectFailed }
})

// React hook — same blind spot
export function useFoo() {
  const [items, setItems] = useState([])
  const selectFailed = () => { /* … */ }  // NOT indexed
  return { items, selectFailed }
}

• search_graph(name_pattern: "selectFailed") → 0 results
• search_code("selectFailed") → misses it too (only doc/text mentions)
• Only the outer useFooStore / useFoo is indexed.

Suggestion

Generalize extraction so inner function/arrow-const declarations inside recognized factory/setup callbacks become child nodes (DECLARED_IN/MEMBER_OF the container). Likely one pass covers defineStore(name, setup), exported composables/hooks (useX returning an object/closure), and the already-noted Zustand create(() => ({…})). Could be framework-gated or heuristic if needed.

Environment: v0.7.0, Windows 11, Vue 3 + Pinia (~16k-node graph).

[DeusData]

Thanks — good catch. Inner declarations of factory/setup callbacks (Pinia setup stores being the canonical case) are exactly the kind of structure the extractor should surface; queued for triage.

[Enferlain]

A current Python case appears to exercise the same broader inner-declaration gap and may be useful when defining the acceptance coverage for this issue.

def _maybe_cache_epoch_tokens(...):
    strategies = trainer.strategies

    def tokenize_fn(captions: list[str]) -> list[torch.Tensor]:
        return strategies.tokenize_captions(
            trainer.tokenizers,
            captions,
            cfg.training.max_token_length,
        )

    tokenize_epoch_manifest(..., tokenize_fn, ...)

On a fresh full index:

• search_graph has the enclosing _maybe_cache_epoch_tokens function but no node for nested tokenize_fn.
• trace_path using the expected nested qualified name returns function not found.
• The call inside the nested function produces no CALLS edge to TokenizationStrategy.tokenize_captions or its implementations.
• The enclosing function does have its ordinary calls, including tokenize_epoch_manifest(...), so this is localized to the inner declaration/body rather than a file parse failure.
• Coverage metadata reports no recorded parse gap for the source file.

This affects Python callback/closure-heavy code in the same practical way described here: the outer shell is visible while the inner callable and its dependencies are absent. If #415 is intended to remain specifically scoped to JS/TS factory/setup callbacks, this Python case could instead be split into a language-specific follow-up.