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.
@@ -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": "Codebase Analyzer",
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.2.2",
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-structure",
23
- "file-extensions",
24
- "exclude-directories",
25
- "js",
26
- "ts",
27
- "json-output",
28
- "recursive",
29
- "source-code",
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-quality"
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
- "publish": "npm run compile && npm publish"
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
- # Codebase Analyzer
18
+ ```bash
19
+ npx analyze-codebase ./src
20
+ ```
3
21
 
4
- Codebase Analyzer is a command-line tool that analyzes a specified directory and provides summary information about the code files it contains. It can help you gain insights into your codebase's structure, naming conventions, and content types.
22
+ That's it. No config needed.
5
23
 
6
- ![Example Image](./example-output.png)
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
- ## Features
34
+ ## Quick Start
10
35
 
11
- - Analyzes the specified directory recursively
12
- - Provides summary information about file name cases and content types
13
- - Supports filtering by file extensions and excluding specific directories/files
14
- - Customizable through command-line options
36
+ ```bash
37
+ # Install globally
38
+ npm install -g analyze-codebase
15
39
 
16
- ## Installation
40
+ # Or run instantly with npx
41
+ npx analyze-codebase .
42
+ ```
17
43
 
18
- You can install Codebase Analyzer globally using NPM:
44
+ ### Find unused i18n translation keys
19
45
 
20
46
  ```bash
21
- npm install -g analyze-codebase
22
- ```
47
+ # With npx (no install needed)
48
+ npx analyze-codebase i18n ./src --file locales/en.json
23
49
 
24
- or use with npx
50
+ # If installed globally
51
+ analyze-codebase i18n ./src --file locales/en.json
25
52
 
26
- ```bash
27
- npx analyze-codebase ./MyProject --exclude node_modules dist --extensions .tsx .ts
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
- ## Usage
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
- To analyze a directory, use the analyze command followed by the directory path. Here's an example:
62
+ ### Setup a config file (optional)
33
63
 
34
64
  ```bash
35
- analyze-codebase ./MyProject --exclude node_modules dist --extensions .tsx .ts
65
+ analyze-codebase init
36
66
  ```
37
67
 
38
- ## Options
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
- - -f, --framework <framework>: Specify the framework used in the codebase.
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
- - --checkFileNames [checkFileNames]: Check file names. Default: true.
72
+ ### 1. Codebase Structure Analysis
46
73
 
47
- - --checkFileContent [checkFileContent]: Check file content. Default: true.
74
+ Recursively scans your project and provides a breakdown of:
48
75
 
49
- - -w or --writeJsonOutput [writeJsonOutput]: Write json putput for tracking. Default false
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
- ## Black list
80
+ ```bash
81
+ # Analyze TypeScript files in your src directory
82
+ analyze-codebase ./src --extensions ts tsx
52
83
 
53
- analyze-codebase by default have a black list of folder names which don't want to analyze which this directories mostly should be out of analyze (i.e. dist or static files)
84
+ # Analyze with a specific framework tag
85
+ analyze-codebase ./src -f react --extensions ts tsx js jsx
86
+ ```
54
87
 
55
- - node_modules
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
- ## Examples
90
+ ### 2. Unused i18n Translation Key Detection
65
91
 
66
- Analyze a directory with default options:
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
- Analyze a directory with a specified framework and file extensions:
98
+ **What it does:**
73
99
 
74
- ```bash
75
- analyze-codebase ./src -f react --extensions .js .jsx .ts .tsx
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
- Exclude specific directories from the analysis:
106
+ **Supported patterns** - it understands how real apps use translations:
79
107
 
80
- ```bash
81
- analyze-codebase ./src --exclude node_modules dist
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
- Analyze only file names
122
+ When dynamic keys are detected, all child keys under that namespace are automatically marked as used - preventing false positives.
85
123
 
86
- ```bash
87
- analyze-codebase ./src --exclude node_modules dist --checkFileContent=false
88
- ```
124
+ ### 3. Export Reports
89
125
 
90
- Analyze only file content
126
+ Generate shareable reports in three formats:
91
127
 
92
128
  ```bash
93
- analyze-codebase ./src --exclude node_modules dist --checkFileNames=false
94
- ```
129
+ # Beautiful styled HTML report
130
+ analyze-codebase ./src --export html --output report.html
95
131
 
96
- Write json output of this analyze
132
+ # Spreadsheet-friendly CSV
133
+ analyze-codebase ./src --export csv --output data.csv
97
134
 
98
- ```bash
99
- analyze-codebase -w
135
+ # Structured JSON for programmatic use
136
+ analyze-codebase ./src --export json --output results.json
100
137
  ```
101
- or
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 --writeJsonOutput
146
+ analyze-codebase ./src --watch
105
147
  ```
106
148
 
107
- ## Contribution
149
+ - 500ms debounce to prevent excessive runs
150
+ - Graceful Ctrl+C shutdown
151
+ - Works with all analysis options
108
152
 
109
- We welcome contributions to enhance the functionality and features of Codebase Analyzer. To contribute to the project, please follow these steps:
153
+ ### 5. Parallel Processing
110
154
 
111
- Fork the repository by clicking on the "Fork" button at the top right corner of this page.
155
+ Files are processed in parallel with auto-optimized concurrency:
112
156
 
113
- Clone the forked repository to your local machine:
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
- git clone https://github.com/your-username/analyze-codebase.git
164
+ # Override if needed
165
+ analyze-codebase ./src --max-concurrency 50
117
166
  ```
118
167
 
119
- Create a new branch for your feature or bug fix:
168
+ ## All CLI Options
120
169
 
121
- ```bash
122
- git checkout -b feature/your-feature-name
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
- or
191
+ ## Config File
126
192
 
193
+ Create `.analyze-codebase.json` in your project root (or run `analyze-codebase init`):
127
194
 
128
- ```bash
129
- git checkout -b bugfix/your-bug-fix
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
- Make your modifications and additions to the codebase.
207
+ The config is auto-discovered by searching up the directory tree. CLI flags always take precedence over config values.
133
208
 
134
- Test your changes thoroughly to ensure they do not introduce any issues.
209
+ ## Real-World Examples
135
210
 
136
- Commit your changes with a descriptive commit message:
211
+ ### Code Review Preparation
137
212
 
138
213
  ```bash
139
- git commit -m "Add your commit message here"
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
- Push your changes to your forked repository:
218
+ ### CI/CD Pipeline
143
219
 
144
220
  ```bash
145
- git push origin feature/your-feature-name
221
+ # Silent mode for CI - just export the data
222
+ analyze-codebase ./src --no-progress --export json --output analysis.json
146
223
  ```
147
- or
224
+
225
+ ### Translation Cleanup Sprint
148
226
 
149
227
  ```bash
150
- git push origin bugfix/your-bug-fix
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
- Open a pull request (PR) from your forked repository to the original repository. Provide a clear and concise description of your changes in the PR.
232
+ ### Monorepo Analysis
154
233
 
155
- Wait for the maintainers to review your PR. They may provide feedback or request additional changes.
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
- Once your PR is approved, it will be merged into the main branch, and your contributions will become a part of the Codebase Analyzer project.
240
+ ## Contributing
158
241
 
159
- Please ensure that you adhere to our code of conduct and follow the guidelines provided in the CONTRIBUTING.md file for a smooth and collaborative contribution process.
242
+ Contributions are welcome! Here's how:
160
243
 
161
- Thank you for your interest in improving Codebase Analyzer! Your contributions are highly appreciated.
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
- This project is licensed under the MIT License.
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>