Source file type predicates and path helpers.
Pure functions for detecting file types by extension and extracting component names from paths. No configuration dependency — these are the building blocks used by source-config.ts.
@see source-config.ts for configuration-aware functions (isSource, extractPath, etc.) @see analyze.ts for consumers (analyze, analyzeFromFiles)
15 declarations
also exported from index.ts
AnalyzerType import type {AnalyzerType} from 'svelte-docinfo/source.js'; Analyzer type for source files.
'typescript' — TypeScript/JS files analyzed via TypeScript compiler API'svelte' — Svelte components analyzed via svelte2tsx + TypeScript compiler API'css' — CSS files included as modules with no declarations'json' — JSON files included as modules with no declarations(modulePath: string): string import {getComponentName} from 'svelte-docinfo/source.js'; Extract component name from a Svelte module path.
modulePathstringstring getComponentName('Alert.svelte') // => 'Alert'
getComponentName('components/Button.svelte') // => 'Button'also exported from index.ts
(path: string): AnalyzerType | null import {getDefaultAnalyzer} from 'svelte-docinfo/source.js'; Default analyzer resolver based on file extension.
.svelte → 'svelte'.ts, .js → 'typescript'.css → 'css'.json → 'json'null (skip)pathstringAnalyzerType | null (path: string): boolean import {isCss} from 'svelte-docinfo/source.js'; Check if a path is a CSS file.
pathstringboolean (path: string): boolean import {isJson} from 'svelte-docinfo/source.js'; Check if a path is a JSON file.
pathstringboolean (path: string): boolean import {isSvelte} from 'svelte-docinfo/source.js'; Check if a path is a Svelte component file.
pathstringboolean (name: string): boolean import {isSvelte2tsxGeneratedExport} from 'svelte-docinfo/source.js'; Whether an export name from a svelte2tsx virtual is generated machinery
rather than an author declaration: the default slot (svelte2tsx's own
component export — the component declaration is synthesized separately)
plus every isSvelte2tsxInternal shape. The one rule shared by the Svelte
export filter (analyzeSvelteModule), the alias-registry pre-pass skip,
and warnAliasLost's virtual guard — only meaningful for names read off a
virtual's export table (a plain TS module's default export is real).
namestringboolean (name: string): boolean import {isSvelte2tsxInternal} from 'svelte-docinfo/source.js'; Whether a symbol name is an internal svelte2tsx identifier — a generated
name that must not appear in documentation output: $$ComponentProps,
$$render, __sveltets_Render, and the synthesized component class/type
alias <ComponentName>__SvelteComponent_. Building block for
isSvelte2tsxGeneratedExport, which adds the default slot.
namestringboolean (path: string): boolean import {isSvelteVirtualPath} from 'svelte-docinfo/source.js'; Whether a path names a svelte2tsx virtual file (carries SVELTE_VIRTUAL_SUFFIX).
pathstringboolean (path: string): boolean import {isTypescript} from 'svelte-docinfo/source.js'; Check if a path is a TypeScript or JS file.
Includes both .ts and .js files since JS files are valid in TS projects.
Excludes .d.ts declaration files — use a custom getAnalyzerType to include them.
pathstringboolean (text: string): string import {scrubVirtualSuffixes} from 'svelte-docinfo/source.js'; Remove every occurrence of the virtual suffix from free-form text.
The text twin of stripVirtualSuffix: that one strips a path's trailing
suffix, this one scrubs a prose string (a diagnostic message) that may
embed virtual paths anywhere. Both readings of the suffix live here so a
suffix change has one home.
textstringstring also exported from index.ts
SourceFileInfo import type {SourceFileInfo} from 'svelte-docinfo/source.js'; File information for source analysis.
Provides file content to analysis functions from any source: file system, build pipeline, or in-memory.
Note: content is required to keep analysis functions pure (no hidden I/O).
Callers are responsible for reading file content before analysis.
idAbsolute path to the file.
type string
contentFile content (required - analysis functions don't read from disk).
type string
dependencies?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.
type readonly string[]
(path: string): string import {stripVirtualSuffix} from 'svelte-docinfo/source.js'; Strip the svelte2tsx virtual file suffix from a path, if present.
Maps Component.svelte.__svelte2tsx__.ts back to Component.svelte.
Returns the path unchanged if the suffix is not present.
pathstringstring "__SvelteComponent_" import {SVELTE_COMPONENT_ALIAS_SUFFIX} from 'svelte-docinfo/source.js'; Suffix svelte2tsx appends to the synthesized component const/type alias
(<Name>__SvelteComponent_). One of the generated-identifier shapes
isSvelte2tsxInternal filters.
".__svelte2tsx__.ts" import {SVELTE_VIRTUAL_SUFFIX} from 'svelte-docinfo/source.js'; Suffix appended to .svelte file paths to create virtual TypeScript file paths.
Used by svelte2tsx integration: Component.svelte → Component.svelte.__svelte2tsx__.ts.