Atlas locates where a behavior is implemented in JavaScript by attacking retrieval from three angles at once: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph. You describe what the app does, the semantic index returns candidate declarations even when your words never appear in the source, grep confirms the literal string through ripgrep with include and path filters scoped to your .js files, and findReferences lists every callsite past the index.js barrels. vitest then proves the path is live.
How do you find which JavaScript file implements a behavior?
Atlas finds the JavaScript 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 fuses ranking with reciprocal rank fusion in 2026.
Naming is the core problem in JavaScript retrieval. A rate limiter may be an anonymous arrow function passed to app.use, a retry may be a wrapper called withBackoff exported from a utils barrel, and the actual handler may be three re-exports away from the route that mentions it. codebase_search takes the description instead of the identifier, so a query such as where do we drop duplicate webhook deliveries ranks the function that does the dropping. Every hit comes back with a real .js path, which turns the next step into a read rather than another guess.
When is grep better than semantic search in a JavaScript project?
Atlas ships grep next to 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 such as process.env.API_KEY across your JavaScript sources takes 1 pass and involves no ranking at all.
grep is the confirmation pass in a JavaScript search. Once codebase_search has proposed a candidate, a ripgrep regex shows every literal occurrence of the symbol: the module that defines it, the barrel that re-exports it, the npm script that references it in package.json, and the vitest spec that mocks it. Include and path filters keep the sweep on your source and off vendored bundles. Semantic search proposes and grep verifies, which is precisely why Atlas ships codebase_search, grep, and the lsp tool rather than one fuzzy search box.
How do you find every callsite of a JavaScript function with the lsp tool?
Atlas uses the lsp tool's findReferences operation to list every callsite of a JavaScript symbol, and workspaceSymbol to jump to a declaration by name. The symbol graph is the third of 3 angles, after codebase_search for meaning and grep for exact text, and it is the one that survives re-export barrels.
findReferences turns a candidate into a call path. Given a handler that codebase_search surfaced, the lsp tool lists each callsite: the route registration, the middleware that wraps it, the vitest spec that exercises the failure branch. workspaceSymbol runs the other direction, jumping straight to a declaration you can already name without hunting through src/. Atlas then summarizes the call path back to you with concrete file and line references, so each hop is something you can open with read instead of a paraphrase you have to trust.
What does Atlas do when a JavaScript file path is wrong?
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 a mistyped src/handlers/webhook.js never comes back as a misleading empty result during a JavaScript search in 2026.
Silent failure is dangerous in code search, because an empty result looks like proof the behavior does not exist. Atlas's read tool refuses to be quiet: a missing path returns File not found along with a Did you mean list of near matches, which in a JavaScript tree usually points straight at the file you meant. Safety continues past reading. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a JavaScript search session cannot turn into an edit of a .js module without you seeing it.
How do you prove the JavaScript code you found actually runs?
Atlas proves a located JavaScript symbol is live by running vitest against the spec that covers it. Install first with pnpm, run vitest, and watch whether an assertion touches the branch findReferences pointed at. Those 3 commands settle the question in 2026, and prettier keeps an exploratory edit from becoming a formatting diff.
Reading a function tells you what it should do, and vitest tells you what it does. After the lsp tool's findReferences operation produces the callsites, run vitest on the spec covering them and check whether the branch you care about is actually exercised. Silence there is a finding: you have located a real coverage gap rather than the wrong file. pnpm keeps the install reproducible so the run reflects the locked dependency tree. prettier keeps an exploratory edit from turning into a formatting diff, so the .js line you inspect is the line you actually changed.
Which JavaScript patterns hide a behavior from grep?
Atlas works around the 3 JavaScript patterns that defeat a name search: an anonymous arrow function passed straight to app.use, a default export renamed on its way through an index.js barrel, and a handler registered dynamically from a config object. codebase_search ranks all 3 by meaning.
Anonymous functions have no name to grep for, which is why a JavaScript rate limiter or error handler frequently cannot be found by text search at all. A default export can be renamed at every hop through an index.js barrel, so the name at the callsite and the name at the definition differ. Dynamic registration from a config object hides the wiring inside a loop. codebase_search returns the declaration by meaning, the lsp tool's findReferences operation proves the callsites, and a vitest run under pnpm confirms which branch actually executes.
Which commands do you run while tracking down JavaScript behavior?
Tracking down a behavior in a JavaScript repo takes 3 commands beyond the Atlas tools: pnpm to install the workspace from package.json, vitest to run the spec covering the callsite, and prettier to keep an exploratory edit from becoming a formatting diff.
pnpm comes first because a vitest run against a stale node_modules tree proves nothing: the module you are chasing may resolve to a different version. vitest comes second, aimed at the specific spec that covers the callsite the lsp tool listed, not the whole suite. prettier comes last, and only if you touched a .js file while looking, because reformatting buries the one line you care about. The npm scripts in package.json are worth reading first, since they name the exact vitest invocation the project expects rather than the one you assume.
Step by step
- 01Describe the behavior to codebase_search in plain language; the semantic index returns candidate JavaScript 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 your .js sources rather than bundled 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 past the index.js re-export barrels, and workspaceSymbol to jump to the declaration by name.
- 05Install the workspace with pnpm, then run vitest on the spec covering that callsite to prove the JavaScript path 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 function is defined in a large JavaScript project
- Use the lsp tool's workspaceSymbol operation to jump to the declaration by name, or describe the behavior to codebase_search when you do not know the name. Atlas indexes code by AST declarations using tree-sitter, so it returns the real function.
- how do I find all callers of a JavaScript function
- Run the lsp tool's findReferences operation on the symbol. Atlas returns every callsite with concrete file and line references, which beats grepping a name that gets renamed on the way through an index.js re-export.
- grep or semantic search for finding JavaScript code
- Use both. grep takes a real regex plus include and path filters and runs through ripgrep, confirming exact text. codebase_search finds candidate declarations by meaning even when your words never appear in the JavaScript source.
- how do I find which middleware handles a request in a JavaScript app
- Describe the behavior to codebase_search rather than guessing the middleware name, since it is often an anonymous function. The semantic index ranks the declaration, then the lsp tool's findReferences operation shows where it is registered.
- why does Atlas return File not found for a JavaScript path
- Atlas's read tool fails loudly on a bad path and returns File not found plus a Did you mean list of near matches. The message means the path is wrong, not that the code is missing, so pick the suggested path and retry.
- can Atlas run vitest to confirm the code path it found
- Yes. Atlas can install with pnpm and run vitest against the spec covering the callsite. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so nothing executes unapproved.
- can I search a private JavaScript codebase with an AI agent
- Yes. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, so codebase_search still works on a proprietary package.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 JavaScript in 2026
In 2026, Atlas empowers JavaScript developers with a terminal-native AI coding agent. It indexes code by AST, uses local embeddings, and offers permission-gated tools for safe, efficient development.
Research a Third-Party API Before Integrating It in JavaScript with Atlas (2026)
Atlas uses websearch and webfetch to pull live API docs into context before you write JavaScript, so your Node or browser integration matches the real endpoints in 2026.
Extract a shared helper from duplicated code in JavaScript with Atlas (2026)
Collapse copy-pasted JavaScript into one helper in 2026: Atlas finds semantic duplicates with codebase_search, writes the module, and swaps each copy with apply_patch.
Upgrade a Dependency and Fix the Breakage in JavaScript with Atlas (2026)
Atlas upgrades a JavaScript dependency through pnpm, fetches the release notes with webfetch, and fixes every callsite the build and vitest report, one diff at a time.
Write Unit Tests for Untested JavaScript Code with Atlas (2026)
Atlas enumerates a JavaScript module's exports with the lsp tool, copies your existing vitest conventions, writes the spec file, and runs vitest with the bash tool.
Migrate a deprecated API across every callsite in JavaScript with Atlas (2026)
How Atlas migrates a deprecated JavaScript API across every callsite in 2026: lsp findReferences enumerates callers, todowrite tracks them, apply_patch migrates each one.
Refactor a Legacy Module in JavaScript with Atlas (2026)
Refactor a legacy JavaScript module with Atlas in 2026: enumerate callsites with the lsp tool, restructure with apply_patch, and prove behavior with vitest.