typescript-program.ts

Persistent language-service handle that drives a ts.Program incrementally.

Owns the LS, document registry, and a `Map<path, {content, version, scriptKind}>` of "owned" files (real source files + virtuals pushed via setFile). Files not in the owned map are read from disk on demand by the LS host.

Each setFile(path, entry) bumps the version when content or script kind differs from cache, so the next getProgram() reparses only the changed file. Calling getProgram() with no version bumps returns the same ts.Program as the previous call (reference-stable when nothing changed).

Options for createAnalysisLanguageService.

Options for createAnalysisProgram.

Decorate a compiler host so virtualFiles shadow the filesystem — getSourceFile (honoring per-entry scriptKind), fileExists, readFile, and directoryExists.

Entries are copied to minimal {content, scriptKind} records so the host's closures don't retain larger caller objects (a SvelteVirtualFile's source map, say) for the program's lifetime. The copied map is returned so callers layering module resolution on top (.svelte specifier mapping) can key it off the same snapshot instead of re-capturing the caller's map. The entry set is fixed at decoration time — the returned ReadonlyMap and the directory index are built in the same pass, so no host answer can be served from a staler view of the set than another (a LanguageService is the mutable counterpart; see createAnalysisLanguageService).

Create a persistent language service for incremental analysis.

The LS owns parsed source ASTs and checker state across calls. Use the returned handle to push file-content updates (setFile / deleteFile) between analysis passes; subsequent getProgram() calls return either the same ts.Program (no changes since last call) or a fresh one that reuses unchanged files via the document registry.

Create TypeScript program for one-shot analysis.

Use createAnalysisLanguageService instead when you need to analyze the same source set multiple times — the LS path reuses parsed ASTs and checker state across calls.

Path-string counterpart of IsExternalFile, for call sites that hold a file path rather than a ts.SourceFile (re-export classification). Same rule, with declaration-file suffixes standing in for isDeclarationFile.

Deliberately distinct from isSource: isSource answers "does this file emit a module?" while this answers "is this file outside the project?" — an in-root file can fail isSource (the src/lib/internal/ convention, user excludes) while remaining project-local, and conflating the two mis-files project-local re-exports as external-package facts.

Create an empty OwnedDirIndex.

Predicate for determining whether a TypeScript source file is external to the project. Used by intersection type filtering to separate user-authored properties from library/framework properties.

Constructed from ModuleSourceOptions at analysis entry points — files under the source root (e.g., src/lib/) are internal, everything else is external.

Load and parse tsconfig.json into compiler options + initial file list.

Shared by createAnalysisProgram and createAnalysisLanguageService so tsconfig-resolution behavior stays identical across the two paths. Also useful directly when a caller needs only CompilerOptions (e.g., import resolution via ts.resolveModuleName) without the cost of building a full ts.Program.

Base configuration shared by every entry point in this module.

projectRoot + tsconfig + compilerOptions together drive loadTsconfig, which is also exposed publicly. AnalysisProgramOptions and AnalysisLanguageServiceOptions extend this with their own fields.

Ancestor-directory index over a path set, maintained as the set mutates.

Module resolution probes directoryExists before trying file candidates inside it (directoryProbablyExists): a directory reported absent has every candidate recorded as a failed lookup with fileExists never consulted, so a directory that exists only as the prefix of served in-memory paths must report present. Refcounted per ancestor so removal is exact — O(path depth) per mutation, O(1) per query; a per-probe scan of the path set would multiply into resolution's hot path (bare-specifier resolution walks many nonexistent ancestor node_modules directories per import).

The index owns its path set, so add/remove are idempotent and a caller can't skew the refcounts by double-adding or by removing something it never added (which would drop an ancestor still holding live paths). Membership bookkeeping therefore stays here rather than in each caller's guard.

A host-served file entry: content plus optional parser treatment.