analyze-codebase 1.2.2 → 1.3.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/settings.local.json +17 -0
- package/.vscode/settings.json +5 -0
- package/CHANGELOG.md +137 -0
- package/ENHANCEMENTS.md +257 -0
- package/FEATURES.md +225 -0
- package/dist/analyze/i18n/index.js +477 -0
- package/dist/analyze/index.js +187 -25
- package/dist/index.js +237 -16
- package/dist/utils/__tests__/config.test.js +94 -0
- package/dist/utils/__tests__/progress.test.js +37 -0
- package/dist/utils/cancellation.js +75 -0
- package/dist/utils/config.js +83 -0
- package/dist/utils/export.js +218 -0
- package/dist/utils/output.js +137 -41
- package/dist/utils/progress.js +51 -0
- package/dist/utils/spinner.js +61 -0
- package/dist/utils/watch.js +99 -0
- package/docs/agents/developer-agent.md +818 -0
- package/docs/agents/research-agent.md +244 -0
- package/package.json +44 -20
- package/readme.md +178 -83
- package/tsconfig.json +5 -2
- package/vitest.config.ts +12 -0
|
@@ -0,0 +1,244 @@
|
|
|
1
|
+
# Research Agent Documentation
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
This document defines the rules and guidelines for the Research Agent, an AI agent designed to manage and maintain documentation for the Uygar Koleji project. The agent follows Cursor best practices and operates in English, unlike feature documentation which is in Turkish.
|
|
6
|
+
|
|
7
|
+
## Purpose
|
|
8
|
+
|
|
9
|
+
The Research Agent is responsible for:
|
|
10
|
+
|
|
11
|
+
- Maintaining and updating project documentation
|
|
12
|
+
- Researching and documenting features, implementations, and technical details
|
|
13
|
+
- Ensuring documentation follows Cursor best practices
|
|
14
|
+
- Keeping documentation accurate and up-to-date
|
|
15
|
+
- Assisting with code understanding and feature discovery
|
|
16
|
+
|
|
17
|
+
## Language
|
|
18
|
+
|
|
19
|
+
**All Research Agent documentation and interactions should be in English**, even though:
|
|
20
|
+
|
|
21
|
+
- Feature documentation (`docs/features.md`) is in Turkish
|
|
22
|
+
- Goal documentation (`docs/goals/*.md`) is in Turkish
|
|
23
|
+
- Project info (`docs/project-info.md`) is in Turkish
|
|
24
|
+
|
|
25
|
+
This separation allows:
|
|
26
|
+
|
|
27
|
+
- Technical documentation to remain accessible to international developers
|
|
28
|
+
- Clear distinction between user-facing (Turkish) and developer-facing (English) documentation
|
|
29
|
+
- Better integration with Cursor's AI capabilities
|
|
30
|
+
|
|
31
|
+
## Cursor Best Practices
|
|
32
|
+
|
|
33
|
+
### 1. Documentation Structure
|
|
34
|
+
|
|
35
|
+
Follow Cursor's recommended documentation structure:
|
|
36
|
+
|
|
37
|
+
```
|
|
38
|
+
docs/
|
|
39
|
+
├── features.md (Turkish - user-facing features)
|
|
40
|
+
├── project-info.md (Turkish - project overview for agents)
|
|
41
|
+
├── goals/
|
|
42
|
+
│ ├── docs.md (Turkish - planned features)
|
|
43
|
+
│ └── goal-slug.md (Turkish - detailed goal documentation)
|
|
44
|
+
├── agents/
|
|
45
|
+
│ └── research-agent.md (English - this file)
|
|
46
|
+
└── [other technical docs] (English)
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
### 2. Code Documentation Standards
|
|
50
|
+
|
|
51
|
+
- **Inline Comments**: Use clear, concise comments explaining "why" not "what"
|
|
52
|
+
- **Function Documentation**: Document all public functions with JSDoc/TSDoc
|
|
53
|
+
- **Type Definitions**: Always include TypeScript types for better IDE support
|
|
54
|
+
- **Examples**: Include code examples for complex functions
|
|
55
|
+
|
|
56
|
+
### 3. Markdown Formatting
|
|
57
|
+
|
|
58
|
+
- Use proper heading hierarchy (H1 → H2 → H3)
|
|
59
|
+
- Include table of contents for long documents
|
|
60
|
+
- Use code blocks with language identifiers
|
|
61
|
+
- Include diagrams using Mermaid or ASCII art
|
|
62
|
+
- Use tables for structured data
|
|
63
|
+
|
|
64
|
+
### 4. File Organization
|
|
65
|
+
|
|
66
|
+
- One concept per file
|
|
67
|
+
- Use descriptive file names
|
|
68
|
+
- Group related files in directories
|
|
69
|
+
- Keep files focused and concise
|
|
70
|
+
|
|
71
|
+
## Agent Responsibilities
|
|
72
|
+
|
|
73
|
+
### 1. Documentation Maintenance
|
|
74
|
+
|
|
75
|
+
- **Update Existing Docs**: Keep feature documentation synchronized with code
|
|
76
|
+
- **Create New Docs**: Document new features as they're implemented
|
|
77
|
+
- **Remove Outdated Docs**: Archive or remove obsolete documentation
|
|
78
|
+
- **Cross-Reference**: Maintain links between related documents
|
|
79
|
+
|
|
80
|
+
### 2. Code Analysis
|
|
81
|
+
|
|
82
|
+
- **Feature Discovery**: Analyze codebase to identify features
|
|
83
|
+
- **Implementation Details**: Document how features are implemented
|
|
84
|
+
- **Dependencies**: Track dependencies between features
|
|
85
|
+
- **API Documentation**: Document API endpoints and their usage
|
|
86
|
+
|
|
87
|
+
### 3. Research Tasks
|
|
88
|
+
|
|
89
|
+
- **Technology Research**: Research and document new technologies
|
|
90
|
+
- **Best Practices**: Document industry best practices
|
|
91
|
+
- **Patterns**: Document design patterns used in the codebase
|
|
92
|
+
- **Architecture**: Maintain architecture documentation
|
|
93
|
+
|
|
94
|
+
### 4. Quality Assurance
|
|
95
|
+
|
|
96
|
+
- **Accuracy**: Ensure documentation accurately reflects code
|
|
97
|
+
- **Completeness**: Ensure all features are documented
|
|
98
|
+
- **Clarity**: Ensure documentation is clear and understandable
|
|
99
|
+
- **Consistency**: Maintain consistent style across all documentation
|
|
100
|
+
|
|
101
|
+
## Working with Cursor
|
|
102
|
+
|
|
103
|
+
### 1. Codebase Understanding
|
|
104
|
+
|
|
105
|
+
When asked to understand the codebase:
|
|
106
|
+
|
|
107
|
+
- Use semantic search to find relevant code
|
|
108
|
+
- Read related files to understand context
|
|
109
|
+
- Trace dependencies and relationships
|
|
110
|
+
- Document findings clearly
|
|
111
|
+
|
|
112
|
+
### 2. Feature Documentation
|
|
113
|
+
|
|
114
|
+
When documenting features:
|
|
115
|
+
|
|
116
|
+
- Check `docs/features.md` for existing documentation
|
|
117
|
+
- Verify features in `src/components/dashboard/sidebar/AppSidebar.tsx`
|
|
118
|
+
- Document all features, not just new ones
|
|
119
|
+
- Keep Turkish documentation separate from English technical docs
|
|
120
|
+
|
|
121
|
+
### 3. Goal Documentation
|
|
122
|
+
|
|
123
|
+
When documenting goals:
|
|
124
|
+
|
|
125
|
+
- Check `docs/goals/docs.md` for planned features
|
|
126
|
+
- Create detailed goal documents in `docs/goals/goal-slug.md`
|
|
127
|
+
- Keep goal documentation in Turkish
|
|
128
|
+
- Link goals to related features
|
|
129
|
+
|
|
130
|
+
### 4. Project Information
|
|
131
|
+
|
|
132
|
+
When updating project info:
|
|
133
|
+
|
|
134
|
+
- Update `docs/project-info.md` with project overview
|
|
135
|
+
- Keep it concise and focused on agent needs
|
|
136
|
+
- Include key technical details
|
|
137
|
+
- Maintain links to other documentation
|
|
138
|
+
|
|
139
|
+
## Documentation Workflow
|
|
140
|
+
|
|
141
|
+
### 1. Feature Discovery
|
|
142
|
+
|
|
143
|
+
1. Analyze sidebar component (`AppSidebar.tsx`) to identify all features
|
|
144
|
+
2. Check existing `features.md` for documented features
|
|
145
|
+
3. Identify missing or outdated features
|
|
146
|
+
4. Update `features.md` with missing features (in Turkish)
|
|
147
|
+
|
|
148
|
+
### 2. Goal Documentation
|
|
149
|
+
|
|
150
|
+
1. Check `docs/goals/docs.md` for planned features
|
|
151
|
+
2. Create detailed goal documents as needed
|
|
152
|
+
3. Keep goal documentation in Turkish
|
|
153
|
+
4. Link goals to related features
|
|
154
|
+
|
|
155
|
+
### 3. Technical Documentation
|
|
156
|
+
|
|
157
|
+
1. Document technical implementation details
|
|
158
|
+
2. Keep technical docs in English
|
|
159
|
+
3. Include code examples and diagrams
|
|
160
|
+
4. Maintain cross-references
|
|
161
|
+
|
|
162
|
+
### 4. Agent Documentation
|
|
163
|
+
|
|
164
|
+
1. Keep agent rules and guidelines in English
|
|
165
|
+
2. Update agent documentation as practices evolve
|
|
166
|
+
3. Document agent-specific workflows
|
|
167
|
+
4. Maintain consistency with Cursor best practices
|
|
168
|
+
|
|
169
|
+
## File Naming Conventions
|
|
170
|
+
|
|
171
|
+
- **Feature Docs**: `features.md` (Turkish)
|
|
172
|
+
- **Goal Docs**: `goals/docs.md`, `goals/goal-slug.md` (Turkish)
|
|
173
|
+
- **Agent Docs**: `agents/research-agent.md` (English)
|
|
174
|
+
- **Project Info**: `project-info.md` (Turkish)
|
|
175
|
+
- **Technical Docs**: `TECHNICAL_TOPIC.md` (English)
|
|
176
|
+
|
|
177
|
+
## Code Examples
|
|
178
|
+
|
|
179
|
+
When including code examples:
|
|
180
|
+
|
|
181
|
+
- Use proper syntax highlighting
|
|
182
|
+
- Include context and imports
|
|
183
|
+
- Explain complex logic
|
|
184
|
+
- Show both usage and implementation
|
|
185
|
+
|
|
186
|
+
## Diagrams
|
|
187
|
+
|
|
188
|
+
Use diagrams to illustrate:
|
|
189
|
+
|
|
190
|
+
- Architecture and system design
|
|
191
|
+
- Data flow and relationships
|
|
192
|
+
- Process workflows
|
|
193
|
+
- Component hierarchies
|
|
194
|
+
|
|
195
|
+
Preferred formats:
|
|
196
|
+
|
|
197
|
+
- Mermaid diagrams (for markdown)
|
|
198
|
+
- ASCII art (for simple diagrams)
|
|
199
|
+
- PlantUML (for complex diagrams)
|
|
200
|
+
|
|
201
|
+
## Version Control
|
|
202
|
+
|
|
203
|
+
- Commit documentation changes with code changes
|
|
204
|
+
- Use descriptive commit messages
|
|
205
|
+
- Keep documentation in sync with code
|
|
206
|
+
- Review documentation in PRs
|
|
207
|
+
|
|
208
|
+
## Best Practices Summary
|
|
209
|
+
|
|
210
|
+
1. **Language Separation**: Turkish for user-facing, English for technical
|
|
211
|
+
2. **Structure**: Follow Cursor's recommended structure
|
|
212
|
+
3. **Accuracy**: Keep documentation synchronized with code
|
|
213
|
+
4. **Completeness**: Document all features and goals
|
|
214
|
+
5. **Clarity**: Write clear, understandable documentation
|
|
215
|
+
6. **Consistency**: Maintain consistent style and format
|
|
216
|
+
7. **Cross-Reference**: Link related documents
|
|
217
|
+
8. **Examples**: Include code examples and diagrams
|
|
218
|
+
9. **Updates**: Keep documentation up-to-date
|
|
219
|
+
10. **Quality**: Review and improve documentation regularly
|
|
220
|
+
|
|
221
|
+
## Agent Instructions
|
|
222
|
+
|
|
223
|
+
When working as the Research Agent:
|
|
224
|
+
|
|
225
|
+
1. **Always check existing documentation** before creating new docs
|
|
226
|
+
2. **Verify features** in the codebase, especially `AppSidebar.tsx`
|
|
227
|
+
3. **Maintain language separation**: Turkish for features/goals, English for technical
|
|
228
|
+
4. **Follow Cursor best practices** for documentation structure
|
|
229
|
+
5. **Keep documentation accurate** and synchronized with code
|
|
230
|
+
6. **Use semantic search** to understand the codebase
|
|
231
|
+
7. **Document comprehensively** but concisely
|
|
232
|
+
8. **Cross-reference** related documents
|
|
233
|
+
9. **Update regularly** as the project evolves
|
|
234
|
+
10. **Maintain quality** through review and improvement
|
|
235
|
+
|
|
236
|
+
## Conclusion
|
|
237
|
+
|
|
238
|
+
The Research Agent plays a crucial role in maintaining high-quality documentation for the Uygar Koleji project. By following Cursor best practices and maintaining clear language separation, the agent ensures that documentation remains accurate, comprehensive, and useful for both developers and users.
|
|
239
|
+
|
|
240
|
+
---
|
|
241
|
+
|
|
242
|
+
**Document Version**: 1.0
|
|
243
|
+
**Last Updated**: 2026-01-17
|
|
244
|
+
**Language**: English (as per agent documentation standards)
|
package/package.json
CHANGED
|
@@ -1,11 +1,16 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "analyze-codebase",
|
|
3
|
-
"description": "
|
|
3
|
+
"description": "A powerful CLI tool for analyzing codebase structure, naming conventions, code quality metrics, and detecting unused i18n translation keys",
|
|
4
|
+
"homepage": "https://github.com/mtahagocer/analyze-codebase#readme",
|
|
5
|
+
"bugs": {
|
|
6
|
+
"url": "https://github.com/mtahagocer/analyze-codebase/issues"
|
|
7
|
+
},
|
|
8
|
+
"author": "Taha Gocer <gocermtg@gmail.com>",
|
|
4
9
|
"repository": {
|
|
5
10
|
"type": "git",
|
|
6
11
|
"url": "https://github.com/mtahagocer/analyze-codebase"
|
|
7
12
|
},
|
|
8
|
-
"version": "1.
|
|
13
|
+
"version": "1.3.2",
|
|
9
14
|
"main": "dist/index.js",
|
|
10
15
|
"license": "MIT",
|
|
11
16
|
"bin": {
|
|
@@ -17,35 +22,54 @@
|
|
|
17
22
|
"code-analysis",
|
|
18
23
|
"static-analysis",
|
|
19
24
|
"file-analysis",
|
|
20
|
-
"directory-analysis",
|
|
21
25
|
"naming-conventions",
|
|
22
|
-
"code-
|
|
23
|
-
"
|
|
24
|
-
"
|
|
25
|
-
"
|
|
26
|
-
"
|
|
27
|
-
"
|
|
28
|
-
"
|
|
29
|
-
"
|
|
26
|
+
"code-quality",
|
|
27
|
+
"i18n",
|
|
28
|
+
"unused-translations",
|
|
29
|
+
"translation-keys",
|
|
30
|
+
"internationalization",
|
|
31
|
+
"watch-mode",
|
|
32
|
+
"html-report",
|
|
33
|
+
"csv-export",
|
|
34
|
+
"parallel-processing",
|
|
35
|
+
"cli-tool",
|
|
30
36
|
"developer-tools",
|
|
31
|
-
"code
|
|
37
|
+
"source-code",
|
|
38
|
+
"typescript",
|
|
39
|
+
"react",
|
|
40
|
+
"vue",
|
|
41
|
+
"code-metrics"
|
|
32
42
|
],
|
|
33
43
|
"scripts": {
|
|
34
44
|
"cli": "ts-node ./src/index.ts",
|
|
35
45
|
"dev": "ts-node-dev --respawn --transpile-only ./src/index.ts",
|
|
36
46
|
"start": "node ./dist/index.js",
|
|
37
47
|
"compile": "npx rimraf dist && npx tsc",
|
|
38
|
-
"
|
|
48
|
+
"test": "vitest run",
|
|
49
|
+
"test:watch": "vitest",
|
|
50
|
+
"test:coverage": "vitest run --coverage",
|
|
51
|
+
"prepublishOnly": "npm run compile"
|
|
52
|
+
},
|
|
53
|
+
"dependencies": {
|
|
54
|
+
"boxen": "^5.1.2",
|
|
55
|
+
"chalk": "4.1.0",
|
|
56
|
+
"chokidar": "^4.0.3",
|
|
57
|
+
"cli-progress": "^3.12.0",
|
|
58
|
+
"cli-table3": "^0.6.3",
|
|
59
|
+
"commander": "^10.0.1",
|
|
60
|
+
"fast-glob": "^3.3.2",
|
|
61
|
+
"inquirer": "^12.9.6",
|
|
62
|
+
"ora": "^5.4.1",
|
|
63
|
+
"simple-git": "^3.25.0"
|
|
39
64
|
},
|
|
40
65
|
"devDependencies": {
|
|
66
|
+
"@types/chokidar": "^2.1.7",
|
|
67
|
+
"@types/cli-progress": "^3.11.0",
|
|
68
|
+
"@types/inquirer": "^9.0.7",
|
|
41
69
|
"@types/node": "^20.1.5",
|
|
42
70
|
"ts-node": "^10.9.1",
|
|
43
71
|
"ts-node-dev": "^2.0.0",
|
|
44
|
-
"typescript": "^5.0.4"
|
|
45
|
-
|
|
46
|
-
"dependencies": {
|
|
47
|
-
"chalk": "4.1.0",
|
|
48
|
-
"cli-table3": "^0.6.3",
|
|
49
|
-
"commander": "^10.0.1"
|
|
72
|
+
"typescript": "^5.0.4",
|
|
73
|
+
"vitest": "^2.1.8"
|
|
50
74
|
}
|
|
51
|
-
}
|
|
75
|
+
}
|
package/readme.md
CHANGED
|
@@ -1,164 +1,259 @@
|
|
|
1
|
+
<p align="center">
|
|
2
|
+
<h1 align="center">analyze-codebase</h1>
|
|
3
|
+
<p align="center">
|
|
4
|
+
<strong>Know your codebase. Fix what's broken. Ship with confidence.</strong>
|
|
5
|
+
</p>
|
|
6
|
+
<p align="center">
|
|
7
|
+
<a href="https://www.npmjs.com/package/analyze-codebase"><img src="https://img.shields.io/npm/v/analyze-codebase.svg?style=flat-square&color=blue" alt="npm version"></a>
|
|
8
|
+
<a href="https://www.npmjs.com/package/analyze-codebase"><img src="https://img.shields.io/npm/dm/analyze-codebase.svg?style=flat-square&color=green" alt="npm downloads"></a>
|
|
9
|
+
<a href="https://opensource.org/licenses/MIT"><img src="https://img.shields.io/badge/License-MIT-yellow.svg?style=flat-square" alt="License: MIT"></a>
|
|
10
|
+
<a href="https://github.com/mtahagocer/analyze-codebase"><img src="https://img.shields.io/github/stars/mtahagocer/analyze-codebase?style=flat-square" alt="GitHub stars"></a>
|
|
11
|
+
</p>
|
|
12
|
+
</p>
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
A zero-config CLI that scans your entire project in seconds and gives you a clear picture of what's inside: **file structure**, **naming conventions**, **code-vs-comment ratios**, and most uniquely, **unused i18n translation keys** that bloat your bundles.
|
|
1
17
|
|
|
2
|
-
|
|
18
|
+
```bash
|
|
19
|
+
npx analyze-codebase ./src
|
|
20
|
+
```
|
|
3
21
|
|
|
4
|
-
|
|
22
|
+
That's it. No config needed.
|
|
5
23
|
|
|
6
|
-
|
|
24
|
+
## Why analyze-codebase?
|
|
7
25
|
|
|
26
|
+
| Problem | Solution |
|
|
27
|
+
|---------|----------|
|
|
28
|
+
| "How consistent are our naming conventions?" | Detects 13+ naming cases (camelCase, PascalCase, kebab-case, snake_case...) |
|
|
29
|
+
| "How much of our code is actually comments?" | Breaks down physical lines, source code, comments, TODOs, empty lines |
|
|
30
|
+
| "We have hundreds of translation keys. Which ones are unused?" | Scans your entire codebase for unused i18n keys and safely removes them |
|
|
31
|
+
| "I need a report for my team" | Export as **HTML**, **CSV**, or **JSON** with one flag |
|
|
32
|
+
| "I want this running in my workflow" | Watch mode, CI/CD friendly, config file support |
|
|
8
33
|
|
|
9
|
-
##
|
|
34
|
+
## Quick Start
|
|
10
35
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
- Customizable through command-line options
|
|
36
|
+
```bash
|
|
37
|
+
# Install globally
|
|
38
|
+
npm install -g analyze-codebase
|
|
15
39
|
|
|
16
|
-
|
|
40
|
+
# Or run instantly with npx
|
|
41
|
+
npx analyze-codebase .
|
|
42
|
+
```
|
|
17
43
|
|
|
18
|
-
|
|
44
|
+
### Find unused i18n translation keys
|
|
19
45
|
|
|
20
46
|
```bash
|
|
21
|
-
|
|
22
|
-
|
|
47
|
+
# With npx (no install needed)
|
|
48
|
+
npx analyze-codebase i18n ./src --file locales/en.json
|
|
23
49
|
|
|
24
|
-
|
|
50
|
+
# If installed globally
|
|
51
|
+
analyze-codebase i18n ./src --file locales/en.json
|
|
25
52
|
|
|
26
|
-
|
|
27
|
-
|
|
53
|
+
# Vue project example
|
|
54
|
+
analyze-codebase i18n ./src --file public/locales/en.json --extensions ts tsx vue
|
|
55
|
+
|
|
56
|
+
# With exclusions
|
|
57
|
+
analyze-codebase i18n . --file messages/en.json --exclude dist public
|
|
28
58
|
```
|
|
29
59
|
|
|
30
|
-
|
|
60
|
+
The tool will show all unused keys, then ask **y/n** before removing them. Safe to run — nothing is deleted without confirmation.
|
|
31
61
|
|
|
32
|
-
|
|
62
|
+
### Setup a config file (optional)
|
|
33
63
|
|
|
34
64
|
```bash
|
|
35
|
-
analyze-codebase
|
|
65
|
+
analyze-codebase init
|
|
36
66
|
```
|
|
37
67
|
|
|
38
|
-
|
|
68
|
+
This creates `.analyze-codebase.json` in your project root with your preferred settings. After that, just run `analyze-codebase` - it auto-discovers your config.
|
|
39
69
|
|
|
40
|
-
|
|
41
|
-
- -e, --extensions <extensions...>: Specify the file extensions to include in the analysis. You can provide multiple extensions separated by spaces. Example: -e .js .ts.
|
|
42
|
-
|
|
43
|
-
- -e, --exclude <exclude...>: Specify directories or files to exclude from the analysis. You can provide multiple paths separated by spaces. Example: -e node_modules dist.
|
|
70
|
+
## Features
|
|
44
71
|
|
|
45
|
-
|
|
72
|
+
### 1. Codebase Structure Analysis
|
|
46
73
|
|
|
47
|
-
|
|
74
|
+
Recursively scans your project and provides a breakdown of:
|
|
48
75
|
|
|
49
|
-
- -
|
|
76
|
+
- **File naming conventions** - Are your files consistently named? camelCase? PascalCase? kebab-case? You'll see the exact distribution.
|
|
77
|
+
- **Code content metrics** - Physical lines, source code lines, comments, block comments, single-line comments, TODOs, empty lines.
|
|
78
|
+
- **Smart defaults** - Automatically excludes `node_modules`, `dist`, `build`, `coverage`, `.git`, `.next`, `public`, `test`, `tests`, `mocks`.
|
|
50
79
|
|
|
51
|
-
|
|
80
|
+
```bash
|
|
81
|
+
# Analyze TypeScript files in your src directory
|
|
82
|
+
analyze-codebase ./src --extensions ts tsx
|
|
52
83
|
|
|
53
|
-
|
|
84
|
+
# Analyze with a specific framework tag
|
|
85
|
+
analyze-codebase ./src -f react --extensions ts tsx js jsx
|
|
86
|
+
```
|
|
54
87
|
|
|
55
|
-
-
|
|
56
|
-
- dist
|
|
57
|
-
- build
|
|
58
|
-
- coverage
|
|
59
|
-
- public
|
|
60
|
-
- test
|
|
61
|
-
- tests
|
|
62
|
-
- mocks
|
|
88
|
+
> **Tip:** Extensions work with or without the dot prefix - both `ts` and `.ts` are accepted.
|
|
63
89
|
|
|
64
|
-
|
|
90
|
+
### 2. Unused i18n Translation Key Detection
|
|
65
91
|
|
|
66
|
-
|
|
92
|
+
This is the feature that sets `analyze-codebase` apart. If you work with internationalization, you know the pain: translation files grow over time, keys get orphaned, and nobody knows which ones are still in use.
|
|
67
93
|
|
|
68
94
|
```bash
|
|
69
|
-
analyze-codebase ./src
|
|
95
|
+
analyze-codebase ./src --i18n-file locales/en.json
|
|
70
96
|
```
|
|
71
97
|
|
|
72
|
-
|
|
98
|
+
**What it does:**
|
|
73
99
|
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
100
|
+
1. Parses your translation JSON (supports deeply nested structures)
|
|
101
|
+
2. Flattens all keys to dot-notation paths (e.g., `common.buttons.submit`)
|
|
102
|
+
3. Scans every source file in your project for usage
|
|
103
|
+
4. Shows you exactly which keys are unused
|
|
104
|
+
5. Asks for confirmation, then safely removes them
|
|
77
105
|
|
|
78
|
-
|
|
106
|
+
**Supported patterns** - it understands how real apps use translations:
|
|
79
107
|
|
|
80
|
-
```
|
|
81
|
-
|
|
108
|
+
```js
|
|
109
|
+
// All of these are detected:
|
|
110
|
+
t('key') // react-i18next, i18next
|
|
111
|
+
t("key") // double quotes
|
|
112
|
+
t(`key`) // template literals
|
|
113
|
+
i18n.t('key') // direct i18n object access
|
|
114
|
+
$t('key') // Vue i18n
|
|
115
|
+
translate('key') // custom translate functions
|
|
116
|
+
|
|
117
|
+
// Even dynamic keys:
|
|
118
|
+
t(`namespace.${variable}`) // template literal interpolation
|
|
119
|
+
t('namespace.' + variable) // string concatenation
|
|
82
120
|
```
|
|
83
121
|
|
|
84
|
-
|
|
122
|
+
When dynamic keys are detected, all child keys under that namespace are automatically marked as used - preventing false positives.
|
|
85
123
|
|
|
86
|
-
|
|
87
|
-
analyze-codebase ./src --exclude node_modules dist --checkFileContent=false
|
|
88
|
-
```
|
|
124
|
+
### 3. Export Reports
|
|
89
125
|
|
|
90
|
-
|
|
126
|
+
Generate shareable reports in three formats:
|
|
91
127
|
|
|
92
128
|
```bash
|
|
93
|
-
|
|
94
|
-
|
|
129
|
+
# Beautiful styled HTML report
|
|
130
|
+
analyze-codebase ./src --export html --output report.html
|
|
95
131
|
|
|
96
|
-
|
|
132
|
+
# Spreadsheet-friendly CSV
|
|
133
|
+
analyze-codebase ./src --export csv --output data.csv
|
|
97
134
|
|
|
98
|
-
|
|
99
|
-
analyze-codebase
|
|
135
|
+
# Structured JSON for programmatic use
|
|
136
|
+
analyze-codebase ./src --export json --output results.json
|
|
100
137
|
```
|
|
101
|
-
|
|
138
|
+
|
|
139
|
+
The HTML report includes styled tables, gradient headers, and is ready to share with your team or stakeholders.
|
|
140
|
+
|
|
141
|
+
### 4. Watch Mode
|
|
142
|
+
|
|
143
|
+
Automatically re-runs analysis whenever files change. Perfect for development:
|
|
102
144
|
|
|
103
145
|
```bash
|
|
104
|
-
analyze-codebase --
|
|
146
|
+
analyze-codebase ./src --watch
|
|
105
147
|
```
|
|
106
148
|
|
|
107
|
-
|
|
149
|
+
- 500ms debounce to prevent excessive runs
|
|
150
|
+
- Graceful Ctrl+C shutdown
|
|
151
|
+
- Works with all analysis options
|
|
108
152
|
|
|
109
|
-
|
|
153
|
+
### 5. Parallel Processing
|
|
110
154
|
|
|
111
|
-
|
|
155
|
+
Files are processed in parallel with auto-optimized concurrency:
|
|
112
156
|
|
|
113
|
-
|
|
157
|
+
| Project Size | Default Concurrency |
|
|
158
|
+
|-------------|-------------------|
|
|
159
|
+
| < 100 files | 20 concurrent ops |
|
|
160
|
+
| 100-500 files | 25 concurrent ops |
|
|
161
|
+
| 500+ files | 30 concurrent ops |
|
|
114
162
|
|
|
115
163
|
```bash
|
|
116
|
-
|
|
164
|
+
# Override if needed
|
|
165
|
+
analyze-codebase ./src --max-concurrency 50
|
|
117
166
|
```
|
|
118
167
|
|
|
119
|
-
|
|
168
|
+
## All CLI Options
|
|
120
169
|
|
|
121
|
-
```
|
|
122
|
-
|
|
170
|
+
```
|
|
171
|
+
Usage: analyze-codebase [directory] [options]
|
|
172
|
+
|
|
173
|
+
Options:
|
|
174
|
+
-f, --framework <name> Tag the framework (react, vue, angular...)
|
|
175
|
+
-e, --extensions <ext...> File extensions to include (ts tsx js jsx)
|
|
176
|
+
-exc, --exclude <dirs...> Additional directories to exclude
|
|
177
|
+
--checkFileNames [bool] Analyze file naming conventions (default: true)
|
|
178
|
+
--checkFileContent [bool] Analyze code content metrics (default: true)
|
|
179
|
+
-w, --writeJsonOutput [bool] Write JSON output to track changes over time
|
|
180
|
+
--i18n-file <path> Path to i18n JSON file for unused key detection
|
|
181
|
+
--watch Re-analyze automatically on file changes
|
|
182
|
+
--no-progress Disable progress bar (useful for CI/CD)
|
|
183
|
+
--max-concurrency <number> Max parallel file operations (default: auto)
|
|
184
|
+
--export <format> Export as json, csv, or html
|
|
185
|
+
--output <path> Output file path for export
|
|
186
|
+
|
|
187
|
+
Commands:
|
|
188
|
+
init Create .analyze-codebase.json interactively
|
|
123
189
|
```
|
|
124
190
|
|
|
125
|
-
|
|
191
|
+
## Config File
|
|
126
192
|
|
|
193
|
+
Create `.analyze-codebase.json` in your project root (or run `analyze-codebase init`):
|
|
127
194
|
|
|
128
|
-
```
|
|
129
|
-
|
|
195
|
+
```json
|
|
196
|
+
{
|
|
197
|
+
"extensions": [".ts", ".tsx", ".js", ".jsx"],
|
|
198
|
+
"exclude": ["node_modules", "dist", "build"],
|
|
199
|
+
"checkFileNames": true,
|
|
200
|
+
"checkFileContent": true,
|
|
201
|
+
"framework": "react",
|
|
202
|
+
"showProgress": true,
|
|
203
|
+
"parallel": true
|
|
204
|
+
}
|
|
130
205
|
```
|
|
131
206
|
|
|
132
|
-
|
|
207
|
+
The config is auto-discovered by searching up the directory tree. CLI flags always take precedence over config values.
|
|
133
208
|
|
|
134
|
-
|
|
209
|
+
## Real-World Examples
|
|
135
210
|
|
|
136
|
-
|
|
211
|
+
### Code Review Preparation
|
|
137
212
|
|
|
138
213
|
```bash
|
|
139
|
-
|
|
214
|
+
# Get a full picture before a code review
|
|
215
|
+
analyze-codebase ./src --extensions ts tsx --export html --output review.html
|
|
140
216
|
```
|
|
141
217
|
|
|
142
|
-
|
|
218
|
+
### CI/CD Pipeline
|
|
143
219
|
|
|
144
220
|
```bash
|
|
145
|
-
|
|
221
|
+
# Silent mode for CI - just export the data
|
|
222
|
+
analyze-codebase ./src --no-progress --export json --output analysis.json
|
|
146
223
|
```
|
|
147
|
-
|
|
224
|
+
|
|
225
|
+
### Translation Cleanup Sprint
|
|
148
226
|
|
|
149
227
|
```bash
|
|
150
|
-
|
|
228
|
+
# Find and remove all unused translation keys
|
|
229
|
+
analyze-codebase ./src --i18n-file public/locales/en.json --extensions ts tsx
|
|
151
230
|
```
|
|
152
231
|
|
|
153
|
-
|
|
232
|
+
### Monorepo Analysis
|
|
154
233
|
|
|
155
|
-
|
|
234
|
+
```bash
|
|
235
|
+
# Analyze specific packages
|
|
236
|
+
analyze-codebase ./packages/web --extensions ts tsx -f react
|
|
237
|
+
analyze-codebase ./packages/api --extensions ts -f express
|
|
238
|
+
```
|
|
156
239
|
|
|
157
|
-
|
|
240
|
+
## Contributing
|
|
158
241
|
|
|
159
|
-
|
|
242
|
+
Contributions are welcome! Here's how:
|
|
160
243
|
|
|
161
|
-
|
|
244
|
+
1. Fork the repository
|
|
245
|
+
2. Create your branch: `git checkout -b feature/amazing-feature`
|
|
246
|
+
3. Make your changes and test them: `npm test`
|
|
247
|
+
4. Commit: `git commit -m "feat: add amazing feature"`
|
|
248
|
+
5. Push: `git push origin feature/amazing-feature`
|
|
249
|
+
6. Open a Pull Request
|
|
162
250
|
|
|
163
251
|
## License
|
|
164
|
-
|
|
252
|
+
|
|
253
|
+
MIT - see [LICENSE](./LICENSE) for details.
|
|
254
|
+
|
|
255
|
+
---
|
|
256
|
+
|
|
257
|
+
<p align="center">
|
|
258
|
+
<sub>Built by <a href="https://github.com/mtahagocer">Taha Gocer</a></sub>
|
|
259
|
+
</p>
|