Atlas locates where a behavior is implemented in TypeScript by attacking retrieval from three angles at once: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph. Because Atlas reads your type definitions, path aliases, and strictness settings from tsconfig.json, it can resolve an aliased import to a real .ts file instead of guessing. grep runs through ripgrep for literal confirmation, findReferences lists every callsite, and vitest proves the branch is live.
How do you find which TypeScript file implements a behavior?
Atlas finds the TypeScript file behind a behavior when you describe the behavior to codebase_search. The semantic index returns candidate declarations even when your words do not appear in the source, because Atlas indexes code by AST declarations using tree-sitter and ranks with reciprocal rank fusion in 2026.
Locating behavior in TypeScript is a retrieval problem with a twist: the type layer often names the concept while the implementation does not. A billing retry may be typed as RetryPolicy in an interface, while the code that applies it is an unnamed closure inside a service class. codebase_search takes the description rather than the identifier, so a query such as where do we reject an expired session ranks the function that performs the rejection, and hands it back with its real .ts path. The next step is a read, not another round of guessing at file names.
When should you use grep instead of codebase_search in TypeScript?
Atlas ships grep alongside codebase_search because exact text is a different question from meaning. grep takes a real regex plus include and path filters and runs through ripgrep, so confirming a literal type name such as RetryPolicy across your .ts and .tsx sources is 1 regex away and involves no ranking.
grep is the confirmation pass in a TypeScript search, and it is especially useful for types, because a type name is a literal string that appears in every file that consumes the contract. A ripgrep sweep for an interface name shows the declaration, every import of it, the vitest spec that fixtures it, and any place someone widened it back to any. Include and path filters keep the search on source and off build output. Semantic search proposes, grep verifies, and Atlas ships codebase_search, grep, and the lsp tool precisely because the three are complementary.
How do you find every callsite of a TypeScript symbol with the lsp tool?
Atlas uses the lsp tool's findReferences operation to list every callsite of a TypeScript symbol, and workspaceSymbol to jump to a declaration by name. The symbol graph is the third of 3 angles, and because Atlas reads the path aliases in tsconfig.json, it resolves imports that grep alone would never connect.
findReferences is the operation that turns a TypeScript candidate into a proven call path. Given an exported function that codebase_search surfaced, the lsp tool lists each callsite: the route handler that calls it, the class that injects it, the vitest spec that asserts on its error branch. workspaceSymbol goes the other way, jumping to a declaration by name so you never have to guess whether a type lives in types.ts or in the module that exports the implementation. Atlas then summarizes the call path back to you with concrete file and line references.
What happens when Atlas reads a TypeScript path that does not exist?
Atlas fails loudly on a bad path. Open the best candidate with read, and a wrong guess returns File not found plus a Did you mean list, so an aliased import mistranslated into src/services/billing.ts never comes back as a misleading empty result in 2026.
Silent failure is the worst outcome in code search, because an empty result reads like proof that the behavior does not exist. Atlas's read tool refuses to be quiet about a missing path: it returns File not found along with a Did you mean list of near matches, which in a TypeScript project usually points straight at the .ts file the path alias actually resolves to. Safety extends beyond reading. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a TypeScript search session cannot turn into an edit of a .ts file without you seeing it.
How do you prove the TypeScript code you found is the code that runs?
Atlas proves a located TypeScript symbol is live by running vitest against the spec that covers it. Install with pnpm, run vitest, and check whether an assertion touches the branch findReferences pointed at. Those 3 steps replace guesswork, and prettier keeps an exploratory edit from becoming a formatting diff.
Types tell you what a TypeScript function promises, and vitest tells you what it delivers. After the lsp tool's findReferences operation produces the callsites, run vitest on the covering spec and see whether the branch you identified is actually exercised. Silence is a finding: you have located a coverage gap rather than the wrong file. prettier keeps an exploratory edit from becoming a formatting diff that hides the .ts line you actually changed.
Which TypeScript constructs hide an implementation?
Atlas cuts through the 3 TypeScript constructs that hide an implementation: a path alias from tsconfig.json that points somewhere unexpected, an interface satisfied by a class in another pnpm workspace package, and a generic whose concrete type is decided at the callsite. codebase_search ranks by meaning.
Path aliases in tsconfig.json mean the import specifier and the on-disk path do not match, so a grep for a directory name finds nothing at all. An interface can be declared in one package of a pnpm workspace and implemented in another, which defeats a file-local search. A generic function may be the only code that runs, while the type that decides its behavior is chosen at the callsite. codebase_search finds the declaration by meaning, findReferences proves the callsites, and vitest under pnpm shows which branch executes.
Step by step
- 01Describe the behavior to codebase_search in plain language; the semantic index returns candidate TypeScript declarations even when your words do not appear in the source.
- 02Confirm with grep, which takes a real regex plus include and path filters and runs through ripgrep, scoping the sweep to .ts and .tsx sources rather than build output.
- 03Open the best candidate with read; a wrong guess fails loudly with File not found plus a Did you mean list, so bad paths do not go unnoticed.
- 04Use the lsp tool's findReferences operation to see every callsite, and workspaceSymbol to jump to the TypeScript declaration by name across path aliases from tsconfig.json.
- 05Install with pnpm, then run vitest on the spec covering that callsite to prove the TypeScript branch is live.
- 06Run prettier before any exploratory edit so formatting noise never hides the change you are inspecting.
- 07Ask Atlas to summarize the call path back to you with concrete file and line references.
Frequently asked questions
- how do I find where a type is defined in a TypeScript monorepo
- Use the lsp tool's workspaceSymbol operation to jump to the declaration by name. Atlas reads the path aliases in tsconfig.json, so it resolves an aliased import to the real .ts file rather than a guess.
- how do I find all usages of a TypeScript interface
- Run the lsp tool's findReferences operation on the interface, and confirm with grep, which takes a real regex plus include and path filters and runs through ripgrep across your .ts and .tsx sources.
- how do I find code in TypeScript when I only know what the app does
- Describe the behavior to codebase_search. The semantic index returns candidate declarations even when your words do not appear in the source, because Atlas indexes code by AST declarations using tree-sitter.
- grep vs lsp findReferences in TypeScript
- grep confirms exact text through ripgrep, including any place a contract was widened back to any. findReferences resolves the symbol graph across path aliases, so it catches callsites that a literal text search would miss.
- why does Atlas say File not found for a TypeScript file
- Atlas's read tool fails loudly on a bad path and returns File not found plus a Did you mean list of near matches. In a TypeScript project this usually means a path alias was translated to the wrong on-disk .ts path.
- can Atlas run vitest to confirm the TypeScript code path it found
- Yes. Atlas installs with pnpm and runs vitest against the spec covering the callsite. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs.
- can I search a private TypeScript repo without sending code to a vendor
- Yes. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, so codebase_search works on a private tsconfig.json project.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Locate Where a Behavior Is Implemented with Atlas in 2026
How to locate where a behavior is implemented with Atlas in 2026: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph.
Atlas for TypeScript in 2026
In 2026, TypeScript developers leverage Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas understands your types, ensures code quality, and offers robust safety features.
Document a TypeScript Module With a README Using Atlas (2026 Guide)
Write a README that matches your TypeScript code in 2026. Atlas enumerates exports with lsp documentSymbol, quotes real signatures, and verifies every sample with vitest.
Research a Third-Party API Before Integrating It in TypeScript with Atlas (2026)
Atlas fetches live API documentation with webfetch, then generates typed TypeScript clients from the real response shapes instead of inferring interfaces from memory.
Automate GitHub Issue and Pull Request Triage in TypeScript with Atlas (2026)
Wire the atlas github command into a TypeScript repo's Actions workflow in 2026: set MODEL in provider/model form, gate on write permission, verify with vitest.
Upgrade a Dependency and Fix the Breakage in TypeScript with Atlas (2026)
Bump a TypeScript dependency to a new major in 2026. Atlas drives pnpm through bash, fetches the changelog with webfetch, and fixes every tsc error until vitest is green.
Onboard to an Unfamiliar TypeScript Codebase with Atlas in 2026
Onboard to an unfamiliar TypeScript codebase in 2026. Atlas reads your tsconfig.json, type definitions, and path aliases, then ranks files with codebase_search.
Migrate a Deprecated API Across Every TypeScript Callsite With Atlas (2026)
Move a TypeScript codebase off a deprecated function without missing a caller: Atlas enumerates with lsp findReferences, tracks with todowrite, patches with apply_patch.