Affected builds
CI finds the projects touched by a change, including their dependents, and builds only those instead of rebuilding the whole monorepo.
What it is
Affected builds use the git diff plus a monorepo dependency graph to find which projects a change can influence. Edit a shared package and the tool selects that package plus every app that depends on it; edit one isolated app and the rest of the repository stays out of the run. Nx calls this affected, and Turborepo exposes the same idea through --affected.
Reach for it when one repository contains enough apps and packages that building everything on every pull request wastes minutes or hours. Pair the selection with a build cache: affected logic avoids irrelevant tasks, while caching avoids repeating relevant tasks whose inputs are unchanged.
Gotcha: the answer is only as good as the dependency graph and comparison range. Hidden dependencies, global config files, generated code, or a shallow checkout without the merge base can make the selection wrong. Declare global inputs explicitly and keep a scheduled full build to catch anything the graph missed.
Ask AI for it
Make this monorepo's pull request CI run only affected lint, test, and build tasks. Fetch the pull request base commit with full git history. If the repo uses Turborepo, run turbo run lint test build --affected; if it uses Nx, run nx affected -t lint test build --base=origin/main --head=HEAD. Declare root lockfiles, shared TypeScript config, and CI configuration as global inputs, preserve a nightly full build of every project, and print the selected projects before executing them.