Demonstrating AI-driven blast radius analysis and impact assessment for code changes in Nx monorepos
This repository demonstrates a practical workflow for using AI to analyze dependencies and assess the impact of code changes in a monorepo. It shows how to combine project-level dependency graphs (Nx) with code-level analysis (ts-morph) to efficiently identify all affected code when modifying a shared library.
Real-world scenario: A critical shared library (media-upload) needs a parameter added to its main function. Instead of manually searching through dozens of services, we use automated tools to find all usages and let AI analyze the impact.
user-service- User management and profile featuresinvoice-service- Billing and invoicingsupport-service- Customer support ticketsproduct-service- Product catalogemail-service- Email campaigns and notificationsreport-service- Business analytics and reporting
media-upload- S3 file upload with presigned URLs (the library being changed)
scripts/find-function-usages.ts- Uses ts-morph to find exact function call locationsdocs/ai-workflows/- Complete documentation on the analysis workflowdocs/REQUIREMENTS.md- The change request driving this analysis
Problem: The media-upload library's uploadFile() function has an optional expiresIn parameter for URL expiration times, but most services don't pass it (defaulting to 24 hours). This causes:
- Security issues (sensitive docs exposed too long)
- UX problems (profile pics expire too quickly)
- Compliance violations (audit reports expire before required retention period)
Solution: Add explicit expiry times to all uploadFile() calls based on business requirements (2 hours for sensitive docs → 90 days for public assets).
Challenge: How do we find ALL usages across 6 services with 26+ files?
npm install
npm install -g ts-nodeStep 1: Find affected services (project-level)
npx nx graph --file=project-graph.jsonView which services depend on media-upload:
cat project-graph.json | jq -r '.graph.dependencies | to_entries[] | select(.value[] | .target == "media-upload") | .key'Step 2: Find exact function usages (code-level)
# Search all services
ts-node scripts/find-function-usages.ts uploadFile libs/media-upload
# Or search specific services (faster)
ts-node scripts/find-function-usages.ts uploadFile libs/media-upload user-service invoice-serviceStep 3: View results
cat analysis/function-usages.jsonOutput shows exact file paths, line numbers, and column positions for every uploadFile() call.
ai-dependency-analysis-demo/
├── apps/
│ ├── user-service/ # 4 files (3 use uploadFile)
│ ├── invoice-service/ # 4 files (4 use uploadFile)
│ ├── support-service/ # 4 files (4 use uploadFile)
│ ├── product-service/ # 4 files (3 use uploadFile)
│ ├── email-service/ # 6 files (4 use uploadFile)
│ └── report-service/ # 4 files (4 use uploadFile)
├── libs/
│ └── media-upload/ # The shared library being changed
├── scripts/
│ └── find-function-usages.ts # Analysis script
├── docs/
│ ├── ai-workflows/
│ │ ├── DEPENDENCY-ANALYSIS-GUIDE.md # Complete workflow documentation
│ │ └── README.md
│ └── REQUIREMENTS.md # Change request explaining the task
└── README.md # This file
Key insight: Even though services have 26+ total files, the analysis tools only find the ~21 files that actually call uploadFile(). This targeted approach is 95% faster than searching everything.
- What: Shows which services depend on which libraries
- Why: Filters from 100 services → 6 affected services
- Speed: Seconds for entire workspace
- Output: JSON with project-level dependencies
- What: Finds exact function call locations using TypeScript Compiler API
- Why: Shows file path, line number, column for each call
- Speed: Fast when searching only affected services
- Output: JSON with precise code locations
- Nx narrows scope (project-level filtering)
- ts-morph finds exact locations (code-level precision)
- Combined = Efficient + Accurate
- DEPENDENCY-ANALYSIS-GUIDE.md - Complete technical guide explaining Nx Graph, ts-morph, AST concepts, and the full workflow
- REQUIREMENTS.md - The business requirements driving this code change
This workflow applies to any situation where you need to assess the impact of changing a shared function/library:
- API changes - Adding/removing parameters, changing signatures
- Refactoring - Understanding what code depends on what you're changing
- Deprecation - Finding all usages of code you want to remove
- Testing - Generating test cases based on actual usage patterns
- Security audits - Finding all places sensitive functions are called
- Impact assessment - Understanding blast radius before making changes
- Two-level analysis is crucial - Project graph filters, code analysis pinpoints
- Automation scales - Manually finding 21 function calls across 6 services is error-prone
- AI needs precise inputs - Exact file locations and usage patterns enable accurate test generation
- Tools are language-agnostic - Same approach works for Python, Java, Go (with different tools)
- Workflows are reusable - This pattern applies to any monorepo refactoring task
- Nx - Monorepo build system and dependency graph
- ts-morph - TypeScript AST analysis (wrapper for TypeScript Compiler API)
- TypeScript - Services and library implementation
- Node.js - Runtime environment
This is a demo repository for educational purposes. Feel free to fork and adapt the workflow for your own projects.
MIT