To upgrade a dependency and fix the breakage in a TypeScript project, let Atlas drive `pnpm` through its bash tool, read the real compiler output rather than assuming what broke, and fix the callsites with edit. A major bump changes types before it changes runtime behavior, so the TypeScript compiler enumerates the damage for you: run the typecheck and let every error surface with its file, line, and expected type. When the upgrade needs the changelog, Atlas uses webfetch to pull the release notes so the fixes match the actual breaking changes instead of a guess. The loop ends when the typecheck is clean and `vitest` is green.
How do I upgrade an npm dependency with Atlas in a TypeScript repo?
Atlas runs the `pnpm` upgrade through its bash tool and captures the full output, which is step 1 of the documented 2026 workflow. A major bump in a TypeScript monorepo touches `package.json` and `pnpm-lock.yaml` at once, and if the install output exceeds Atlas's limits it is saved to a file you can read.
Start by having Atlas run the upgrade command through bash in the workspace root. `pnpm` output on a workspace with many packages is verbose, and peer-dependency warnings buried in it are frequently the first real signal that the bump will not be clean. Atlas captures the whole thing and retains the log when it is too large for the transcript. Read the lockfile diff too: a `pnpm-lock.yaml` that pulled a transitive package to a new major is a breakage source the direct dependency's changelog will never mention.
How do I know what actually broke in a TypeScript major version bump?
Do not predict the breakage, compile it. Atlas builds or typechecks the project through bash and lets the TypeScript compiler enumerate every error with its file, line, and expected type. A library major bump in 2026 typically produces dozens of errors, and the compiler list is exhaustive in a way that a guess never is.
TypeScript is unusually good at this job because a type-level breaking change is a compile error, not a runtime surprise. Run the typecheck against your `tsconfig.json` and read the errors in order. A removed export shows up as TS2305. A changed generic signature shows up as TS2345 at every callsite. A narrowed return type shows up wherever the old wide type was relied on. Atlas reads that output directly rather than assuming what broke, which means the fix list is derived from the compiler, not from the model's memory of the library.
How do I get the library's breaking changes into context before editing?
Atlas fetches the library's release notes with the webfetch tool in step 2 of the documented workflow, so the breaking changes are in context before you start editing. A TypeScript major bump often renames an option rather than deleting it, and only the changelog names the replacement, so the compiler error alone leads to a worse fix.
The compiler tells you what no longer typechecks. The changelog tells you what the maintainer intended instead. Both are required. Suppose a client option was removed: the compiler says the property does not exist on the type, which invites deleting it. The release notes say it was renamed and moved onto a nested config object, which is the fix you actually want. With webfetch pulling the real release notes, Atlas's edits match the migration the maintainer documented rather than the shortest path to a green typecheck.
How do I fix each TypeScript callsite against the new package signatures?
Atlas fixes each of the compiler errors with the edit tool, using the lsp tool's goToDefinition operation to inspect the new signatures inside the upgraded package. Jumping into node_modules/@types or the package's own .d.ts in 2026 is what turns a guess about the new API into a read of the actual declaration.
goToDefinition on the changed symbol lands in the upgraded package's type declarations, where the new parameter list, the new generic constraints, and the new return type are stated plainly. That is the source of truth for the fix, and it is available locally after `pnpm` has installed the new version. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each callsite fix in `src/` is reviewed as a patch. Atlas also snapshots file changes as git patches, so a wrong fix across 20 files can be rolled back rather than hand-reverted.
When is a TypeScript dependency upgrade actually done?
A TypeScript dependency upgrade is done when the typecheck is clean and `vitest` is green, which is step 5 of the documented workflow, not when the compiler stops complaining. Types passing proves the shape is right; `vitest` passing proves the behavior survived a major bump that may have silently changed a default.
Re-run the build and the tests through bash until both are clean, then run `prettier` so the edited callsites match the repo's formatting and the diff shows logic rather than whitespace. Finally, review the whole diff before committing: `package.json`, `pnpm-lock.yaml`, and every file you touched. Atlas reads git branches, status, and diffs, so the full change is available for that last read. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the `pnpm` install and the `vitest` run can be allow rules while edits stay on ask.
Step by step
- 01Run the `pnpm` upgrade through Atlas's bash tool and capture the full output; if it exceeds the limits it is saved to a file you can read.
- 02Read the `package.json` and `pnpm-lock.yaml` diff, since a transitive package pulled to a new major is a breakage source the direct changelog never mentions.
- 03Fetch the library's release notes with webfetch so the breaking changes are in context before you start editing.
- 04Typecheck the project against your `tsconfig.json` through bash and let the TypeScript compiler enumerate the breakage rather than predicting it.
- 05Fix each error with the edit tool, using the lsp tool's goToDefinition operation to inspect the new signatures in the upgraded package's .d.ts files.
- 06Re-run the typecheck through bash and repeat until the compiler is clean.
- 07Run `vitest` through bash, since a changed default value can typecheck perfectly and still break behavior.
- 08Run `prettier` on the edited files, then review the whole diff before committing.
Frequently asked questions
- how to upgrade a package to a new major version in typescript
- Have Atlas run the `pnpm` upgrade through bash, fetch the library's release notes with webfetch, then typecheck against your `tsconfig.json` and let the TypeScript compiler enumerate every broken callsite. Fix each with the edit tool and finish when `vitest` is green.
- typescript ts2345 error after dependency upgrade
- TS2345 after a major bump usually means the library changed a generic signature, so every callsite passing the old shape now fails. Use the lsp goToDefinition operation to open the new declaration in the upgraded package and fix the callsites against the real signature.
- atlas fetch changelog for npm package
- Atlas's webfetch tool pulls the library's release notes so the breaking changes are in context before editing. That matters when an option was renamed rather than removed, since the compiler error alone would push you toward deleting it.
- should i trust the compiler or the changelog after an upgrade
- Both. The TypeScript compiler tells you what no longer typechecks. The changelog, pulled with webfetch, tells you what the maintainer intended instead. Fixing from the compiler alone produces the shortest path to green rather than the migration that was documented.
- pnpm-lock.yaml changed unexpectedly after upgrade
- A `pnpm` upgrade can pull a transitive package to a new major, which breaks types without appearing in the direct dependency's changelog. Read the lockfile diff as part of the upgrade rather than treating it as generated noise.
- does typecheck passing mean the upgrade worked
- No. A major bump that silently changes a default value typechecks perfectly and still breaks behavior. Run `vitest` after the typecheck is clean, then run `prettier` on the edited files before reviewing the whole diff.
- can atlas undo a bad dependency migration
- Yes. Atlas snapshots file changes as git patches, so a fix applied across many callsites can be diffed and rolled back rather than hand-reverted. Every edit also surfaces a unified diff for approval before it is written.
- how do i see the new api of an upgraded typescript package
- Use the lsp tool's goToDefinition operation on the changed symbol. It lands in the upgraded package's type declarations, where the new parameter list, generic constraints, and return type are stated plainly, which is the source of truth for the fix.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Upgrade a Dependency and Fix the Breakage with Atlas (2026 Workflow)
How to upgrade a dependency and fix the breakage with Atlas in 2026: bash drives the package manager, webfetch pulls the release notes, edit fixes each compiler error.
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.
Diagnose a hanging or long-running command in TypeScript with Atlas (2026)
Is your pnpm build slow or blocked on stdin? Atlas's bash timeout message tells you which, in 2026, and how to unstick vitest, tsc, and prettier runs that never finish.
Run Atlas Headless in CI in TypeScript with Atlas (2026)
Run Atlas headless in CI on a TypeScript repo in 2026: atlas run is non-interactive by default, supports --format json, and needs pre-approved permissions to reach vitest.
Trace a runtime bug from a stack trace in TypeScript with Atlas (2026)
Go from a production TypeScript stack trace to the responsible line with Atlas in 2026: read each frame at its offset, grep the error string, and pin it with vitest.
Rename a symbol across the repo in TypeScript with Atlas (2026)
Rename a TypeScript symbol across the whole repo in 2026 with Atlas: findReferences for the true callsite list, grep for strings the compiler cannot see, then vitest.