Pre-resolved absolute file paths of modules this file imports.
Opt-in optimization โ when supplied, the session treats this as the
authoritative dependency set for the file and skips its own lex+resolve
pass for this entry. Build-tool integrations (e.g., Gro's filer) that
already maintain a dependency graph can hand it over directly instead of
paying the lex+resolve cost twice.
Omit (undefined) โ default behavior โ the session lexes import
specifiers from content and resolves them via its ImportResolver.
This is the right choice when the caller doesn't already have a graph.
Only include resolved local imports โ node_modules paths are filtered
out at storage time by the configured isSource predicate either way.
Trust contract โ the session treats this array as authoritative and
does not cross-check against the file's content. Edges declared here
are accepted as-is, even if the source code doesn't actually import them;
edges that *are* in content but missing from this array are silently
omitted. The lex+resolve fallback path has no such hole โ its edges are
always grounded in syntactic imports. Build-tool integrations that
supply this field own the correctness of the graph they hand over.
Type-only imports (import type {...}) are the most common asymmetry
versus the lex+resolve path: the default lex (es-module-lexer) keeps
them; pre-resolved callers backed by a Gro-style filer typically drop
them. Both are intentional within their respective contracts.
Cache semantics: the session compares this array element-wise (shallow
equality) against the snapshot stored from the prior call โ a fresh
array with identical contents cache-hits, while any length, element, or
order difference invalidates. Callers that produce fresh arrays per
call (e.g., Gro's [...filer.dependencies.keys()]) reuse the cache
cleanly across persistent-session calls.
Order is significant. Reordering without a content change is treated
as a real change โ sort upstream if you want order-insensitive caching.
Map-iteration-order callers (e.g., a Gro filer emitting
[...filer.dependencies.keys()]) are naturally stable across calls for
the same content, so no defensive sort is needed there.