Atlas onboards you to an unfamiliar JavaScript codebase by mapping the repo where your package.json lives and then starting from meaning rather than filenames. Atlas reads your modules, npm scripts, and bundler config, codebase_search answers a plain-language question against the semantic index, glob shows the directory shape, and read opens only the two or three .js files that matter. pnpm installs the workspace, vitest tells you which suites pass, and prettier shows the formatting baseline.
How do you get up to speed on a JavaScript codebase you did not write?
Atlas gets a JavaScript developer up to speed in 2026 by running where your package.json lives and reading your modules, npm scripts, and bundler config. Then codebase_search takes a plain-language question, for example how requests are authenticated, and returns ranked snippets with real file paths.
The job to be done is building a working mental model of a repository you have never seen before, without reading every file. JavaScript makes that harder than most languages because the entry point is a script name in package.json, the module graph runs through a bundler, and half the interesting code is behind a re-export in an index.js. Atlas starts with the manifest, then asks the semantic index rather than the filesystem. Because Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, a question about request handling ranks the middleware that actually runs, not every file that happens to contain the word request.
What do the npm scripts and bundler config tell Atlas about a JavaScript repo?
Atlas reads the npm scripts and bundler config in package.json before touching source, because those 2 files describe how a JavaScript project actually runs. The scripts block names the vitest command, the build step, and the prettier check, which tells you the contract every contributor is held to.
package.json is the map. The scripts block reveals whether tests run through vitest, whether formatting is enforced with prettier, and which build entry the bundler config consumes. Running glob on the top-level directories then shows the package layout and naming conventions: a single src/ tree, a pnpm workspace with several packages, or a monorepo whose apps each carry their own package.json. Atlas maps your modules, npm scripts, and bundler config in that order, so by the time you open a .js file you already know how it gets built and how it gets tested.
How does Atlas follow the JavaScript module graph without opening every file?
Atlas follows a JavaScript module graph with read plus the lsp tool's goToDefinition operation. Read the 2 or 3 files codebase_search ranked highest, then jump from an import statement such as import { createServer } from './server.js' to the module that defines it, skipping the index.js re-export chain.
Re-export barrels are where JavaScript onboarding usually stalls, because an import path tells you nothing about where the implementation lives. goToDefinition resolves the hop for you, and Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so the snippet it hands back is the whole function or class rather than a random slice. When the chain is deep, Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, which keeps a wide module-graph sweep from eating your main session context.
How does the explore subagent read a JavaScript repo without editing it?
Atlas delegates wide sweeps of a JavaScript repository to the explore subagent through the task tool. The explore subagent carries a deny-by-default permission set that only allows grep, glob, read, bash, webfetch, and websearch, so a sweep across node_modules-adjacent source in 2026 cannot rewrite a .js file.
Onboarding is read-heavy, and a read-heavy agent is exactly where an accidental edit hurts. The explore subagent exists for that reason: it can grep, glob, read, run bash, webfetch, and websearch, and nothing else. Even a bash call inside the sweep, such as a pnpm install, is checked against the same permission rules before it executes. When you do move on to changes, every edit to a .js module arrives as a diff you approve, and vitest tells you whether the change held.
How do you validate a JavaScript codebase with pnpm, vitest, and prettier?
Atlas validates a new JavaScript codebase by running the project's own 3 commands: pnpm to install the workspace, vitest to see which suites pass on a clean checkout, and prettier to learn the formatting baseline. Atlas then records the open questions as a todowrite list for the next turn.
A clean pnpm install followed by vitest is the fastest honest summary of a JavaScript repo's health, and the failures on a fresh clone are onboarding documentation in their own right. prettier tells you the formatting rules without reverse-engineering them from a style guide, which matters before you propose your first diff. The vitest specs and the npm scripts in package.json tell you which modules are actively maintained and which are dormant. Later, when you modernize callbacks to async/await or add Jest tests, you review each diff before it lands.
Which JavaScript files does Atlas read during onboarding?
Atlas reads 4 kinds of JavaScript file during onboarding: package.json for the npm scripts and dependencies, the bundler config for entry points, the index.js barrels that re-export modules, and the vitest spec files that describe behavior. pnpm installs the tree, prettier reveals the formatting rules.
package.json is the contract: the scripts block names the vitest command and the prettier check, and the dependencies block tells you what the bundler config will pull in. index.js barrels are the JavaScript habit that most slows onboarding, because an import path reveals nothing about where the implementation lives. vitest spec files are the closest thing most JavaScript repositories have to a specification, so reading two or three of them beats reading a README. pnpm installs the workspace, prettier settles formatting, and Atlas keeps the leftovers in a todowrite list.
Step by step
- 01Run atlas where your package.json lives, and let Atlas map your modules, npm scripts, and bundler config.
- 02Ask codebase_search a plain-language question, for example how requests are authenticated, and read the ranked .js snippets it returns with file paths.
- 03Run glob on the top-level directories to see the package layout and naming conventions, including any pnpm workspace packages.
- 04Read the two or three JavaScript files codebase_search ranked highest, then follow each import with the lsp tool's goToDefinition operation to get past the index.js barrels.
- 05Delegate a wide module-graph sweep to the explore subagent through the task tool; its permission set only allows grep, glob, read, bash, webfetch, and websearch.
- 06Install the workspace with pnpm, then run vitest to see which suites pass on a clean checkout.
- 07Run prettier to learn the formatting baseline before you propose your first JavaScript edit.
- 08Record what you learned, and every open question, as a todowrite list so it survives into the next turn.
Frequently asked questions
- how do I understand a big JavaScript codebase fast
- Run atlas where your package.json lives so it maps your modules, npm scripts, and bundler config, then ask codebase_search a plain-language question. Read only the two or three .js files it ranks highest instead of opening the whole src tree.
- how do I trace a JavaScript import through an index.js barrel file
- Use the lsp tool's goToDefinition operation. Atlas jumps from the import statement to the module that actually defines the symbol, which skips the re-export chain that makes JavaScript module graphs hard to follow by hand.
- can an AI agent read my JavaScript repo without editing anything
- Yes. Atlas delegates wide sweeps to the explore subagent through the task tool, and that subagent has a deny-by-default permission set allowing only grep, glob, read, bash, webfetch, and websearch. No edit tool is available to it.
- does Atlas work with pnpm workspaces
- Yes. Run atlas where your package.json lives and use glob on the top-level directories to see the package layout, including workspace packages. pnpm remains the package manager you install with, and vitest the runner you test with.
- can Atlas run vitest and prettier on a JavaScript project
- Yes. Atlas runs vitest to show which suites pass on a clean checkout and prettier to reveal the formatting baseline. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs.
- how do I modernize old JavaScript callbacks with an AI agent
- Have Atlas modernize callbacks to async/await or add Jest tests, reviewing each diff. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so nothing lands unseen.
- does Atlas send my JavaScript source to a third-party server
- Not necessarily. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, which matters when the package.json project you are onboarding to is proprietary.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Onboard to an Unfamiliar Codebase with Atlas in 2026
How to onboard to an unfamiliar codebase with Atlas in 2026: use codebase_search, glob, read, lsp, task, and todowrite to build a mental model fast.
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.
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.
Review a Pull Request in JavaScript With Atlas (2026 Guide)
How to review a JavaScript pull request with Atlas in 2026: bash produces the raw diff, read pulls whole files, and lsp findReferences catches the callers the diff hides.
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.
Plan a Multi-File Change Before Editing in JavaScript with Atlas in 2026
Plan a multi-file JavaScript change before editing in 2026. Atlas's plan agent denies edit outside .atlas/plans/*.md, and plan_exit gates the build agent handoff.
Run Atlas Headless in CI in a JavaScript Project (2026)
Run Atlas non-interactively in a JavaScript pipeline. `atlas run` sends one prompt, streams events to stdout, supports --format json, and exits when the session goes idle.
Locate Where a Behavior Is Implemented in JavaScript with Atlas in 2026
Find the exact JavaScript file and symbol behind a behavior in 2026. Atlas pairs codebase_search with grep over ripgrep and the lsp tool's findReferences.