feat(config): Add TypeScript/JavaScript config file support with defineConfig helper#886
feat(config): Add TypeScript/JavaScript config file support with defineConfig helper#886
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for JavaScript configuration files (.js, .mjs, .cjs) with a defineConfig helper function for better developer experience, providing a more flexible alternative to JSON configuration files.
Key changes:
- Added
defineConfig()helper function for type-safe config definitions with TypeScript support - Updated config file priority order to prioritize JavaScript files over JSON files
- Enhanced documentation to showcase dynamic configuration capabilities with timestamps and environment variables
Reviewed Changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
src/index.ts |
Exports the new defineConfig helper function |
src/config/configSchema.ts |
Implements the defineConfig helper as a type-safe identity function |
src/config/configLoad.ts |
Adds JavaScript config file support with dynamic import and updates priority order |
tests/config/configLoad.test.ts |
Updates test expectations to account for new JS config file priority checks |
tests/config/configLoad.integration.test.ts |
Adds comprehensive integration tests for JS config files |
| `tests/fixtures/config-js/*.js | mjs |
README.md |
Updates documentation with JS config examples and benefits |
website/client/src/*/guide/configuration.md |
Updates website documentation with comprehensive JS config guide |
Summary of ChangesHello @yamadashy, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the flexibility of the configuration system by introducing support for JavaScript-based configuration files. This allows users to define their configurations programmatically, leveraging dynamic values, environment variables, and custom logic. A new Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds multi-format config support and discovery order (TS/CTS/MTS/JS/MJS/CJS/JSON5/JSONC/JSON), introduces defineConfig helper and public export, updates README with full config documentation, replaces repo JSON config with TS, adds jiti dependency, and expands tests with JS/TS fixtures and integration/unit coverage. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant CLI as CLI
participant Loader as loadFileConfig
participant FS as FS
participant JITI as jiti (TS/JS)
participant JSON5 as JSON5 Parser
CLI->>Loader: loadFileConfig(cwd)
Loader->>FS: Probe config files by priority<br/>(.ts, .mts, .cts, .js, .mjs, .cjs, .json5, .jsonc, .json)
alt Found file
Loader->>Loader: ext = getFileExtension(path)
alt ext in [ts, mts, cts, js, mjs, cjs]
Loader->>JITI: import default export
JITI-->>Loader: config object
else ext in [json5, jsonc, json]
Loader->>JSON5: parse file
JSON5-->>Loader: config object
end
Loader-->>CLI: validated config
else None found
Loader-->>CLI: null/undefined (no config)
end
note over Loader,JITI: On SyntaxError → throw "Invalid syntax in config file"
note over Loader,JSON5: Unsupported ext → throw error
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying repomix with
|
| Latest commit: |
5b707f5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://5ecab268.repomix.pages.dev |
| Branch Preview URL: | https://feat-js-config-support.repomix.pages.dev |
There was a problem hiding this comment.
Code Review
This pull request introduces a great enhancement by adding support for JavaScript configuration files, which provides more flexibility for users. The implementation is solid, with updated documentation and comprehensive tests. I've added one suggestion to improve the loading of JS config files in long-running processes by preventing module caching. Overall, this is a valuable addition to the project.
src/config/configLoad.ts
Outdated
| if (isJsFile) { | ||
| // Use dynamic import for JavaScript files | ||
| // Convert absolute path to file:// URL for Windows compatibility | ||
| const fileUrl = pathToFileURL(filePath).href; |
There was a problem hiding this comment.
Dynamic import() is cached by Node.js. For a long-running process like the MCP server, this means config changes won't be reloaded without a server restart. Appending a timestamp to the file URL will bust the cache and ensure the latest config is always used on each load.
| const fileUrl = pathToFileURL(filePath).href; | |
| const fileUrl = `${pathToFileURL(filePath).href}?t=${Date.now()}`; |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #886 +/- ##
===========================================
- Coverage 88.82% 74.66% -14.16%
===========================================
Files 109 109
Lines 7612 7653 +41
Branches 1438 1433 -5
===========================================
- Hits 6761 5714 -1047
- Misses 851 1939 +1088 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
PR Review: JavaScript Config File SupportExcellent implementation! This PR adds a much-requested feature with great attention to detail. StrengthsCode Quality
Design Decisions
Testing
Documentation
Issues and Suggestions1. Module Cache Concerns (Medium Priority)Location: src/config/configLoad.ts:105-106 Dynamic imports in Node.js are cached by default. This could cause issues when config is loaded multiple times or in tests. Recommendation: Add cache-busting query parameter to ensure fresh imports each time. This is important for test reliability and development workflows where config changes frequently. 2. Error Handling Edge Case (Low Priority)Location: src/config/configLoad.ts:106 The fallback logic at line 106 uses OR operator which fails if default export is falsy (empty object, false, null). Recommendation: Use explicit undefined check instead of OR operator to handle falsy default exports correctly. 3. Security Note Missing (Low Priority)JavaScript configs execute arbitrary code. Consider adding a security note to documentation that users should only use configuration files from trusted sources. 4. Test Coverage Gaps (Low Priority)Missing test scenarios:
Performance and SecurityPerformance: Negligible impact (1-2ms overhead at startup only) Security:
SummaryThis is a high-quality PR that adds significant value to Repomix. The implementation is solid, well-tested, and properly documented. Recommended Actions:
Overall Rating: 4.5/5Great work! With the minor fixes above, this is ready to merge. |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
website/client/src/en/guide/configuration.md (1)
190-198: Update configuration file locations to reflect new priority order.This section lists only JSON files and doesn't reflect the multi-format support described earlier (lines 7-12). The local configuration discovery should match the priority order: JS/ESM files (
.js,.mjs,.cjs) are checked before JSON5, JSONC, and JSON files.Consider updating this section to:
## Configuration File Locations Repomix looks for configuration files in the following order: -1. Local configuration file (`repomix.config.json`) in the current directory +1. Local configuration files in the current directory: + - JavaScript: `repomix.config.js`, `repomix.config.mjs`, `repomix.config.cjs` + - JSON5: `repomix.config.json5` + - JSONC: `repomix.config.jsonc` + - JSON: `repomix.config.json` 2. Global configuration file: - Windows: `%LOCALAPPDATA%\Repomix\repomix.config.json` - macOS/Linux: `~/.config/repomix/repomix.config.json`website/client/src/ja/guide/configuration.md (1)
190-198: Update configuration file locations to reflect new priority order.This section lists only JSON files and doesn't reflect the multi-format support described earlier (lines 7-12). The Japanese documentation should match the English version and reflect the complete priority order.
Consider updating this section to match the multi-format support:
## 設定ファイルの場所 Repomixは以下の順序で設定ファイルを探します: -1. カレントディレクトリのローカル設定ファイル(`repomix.config.json`) +1. カレントディレクトリのローカル設定ファイル: + - JavaScript: `repomix.config.js`、`repomix.config.mjs`、`repomix.config.cjs` + - JSON5: `repomix.config.json5` + - JSONC: `repomix.config.jsonc` + - JSON: `repomix.config.json` 2. グローバル設定ファイル: - Windows: `%LOCALAPPDATA%\Repomix\repomix.config.json` - macOS/Linux: `~/.config/repomix/repomix.config.json`
🧹 Nitpick comments (2)
website/client/src/en/guide/configuration.md (1)
121-136: Clarify that schema validation applies to JSON-based configs only.The schema validation section doesn't mention that
$schemavalidation is specific to JSON-based configuration files. JavaScript configs usingdefineConfigget type safety through TypeScript instead.Consider adding a note:
## Schema Validation -You can enable schema validation for your configuration file by adding the `$schema` property: +You can enable schema validation for JSON-based configuration files by adding the `$schema` property: ```json { "$schema": "https://repomix.com/schemas/latest/schema.json", "output": { "filePath": "repomix-output.xml", "style": "xml" } }This provides auto-completion and validation in editors that support JSON schema.
+
+Note: JavaScript configuration files get type safety through thedefineConfighelper and TypeScript instead of JSON schema.</blockquote></details> <details> <summary>website/client/src/ja/guide/configuration.md (1)</summary><blockquote> `121-136`: **Clarify that schema validation applies to JSON-based configs only.** The schema validation section should clarify that `$schema` is specific to JSON-based configuration files, while JavaScript configs get type safety through `defineConfig`. Consider adding a note: ```diff ## スキーマ検証 -設定ファイルに`$schema`プロパティを追加することで、スキーマ検証を有効にできます: +JSON形式の設定ファイルに`$schema`プロパティを追加することで、スキーマ検証を有効にできます: ```json { "$schema": "https://repomix.com/schemas/latest/schema.json", "output": { "filePath": "repomix-output.md", "style": "markdown" } }これにより、JSONスキーマをサポートするエディタでの自動補完と検証が可能になります。
+
+注意: JavaScript設定ファイルは、JSONスキーマの代わりにdefineConfigヘルパーとTypeScriptによる型安全性を提供します。</blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: Path: .coderabbit.yaml **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 72f8ab5ba45eb9ad511b12499868bbdc8144cadf and 3283cb7a7349fefe8c83c929e1c3a0b9f44c1eeb. </details> <details> <summary>📒 Files selected for processing (12)</summary> * `README.md` (1 hunks) * `src/config/configLoad.ts` (3 hunks) * `src/config/configSchema.ts` (1 hunks) * `src/index.ts` (1 hunks) * `tests/config/configLoad.integration.test.ts` (1 hunks) * `tests/config/configLoad.test.ts` (4 hunks) * `tests/fixtures/config-js/repomix-dynamic.config.js` (1 hunks) * `tests/fixtures/config-js/repomix.config.cjs` (1 hunks) * `tests/fixtures/config-js/repomix.config.js` (1 hunks) * `tests/fixtures/config-js/repomix.config.mjs` (1 hunks) * `website/client/src/en/guide/configuration.md` (1 hunks) * `website/client/src/ja/guide/configuration.md` (1 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🧬 Code graph analysis (7)</summary> <details> <summary>src/config/configSchema.ts (1)</summary><blockquote> <details> <summary>src/index.ts (2)</summary> * `defineConfig` (33-33) * `RepomixConfigFile` (32-32) </details> </blockquote></details> <details> <summary>tests/fixtures/config-js/repomix-dynamic.config.js (2)</summary><blockquote> <details> <summary>src/config/configSchema.ts (1)</summary> * `defineConfig` (170-170) </details> <details> <summary>src/index.ts (1)</summary> * `defineConfig` (33-33) </details> </blockquote></details> <details> <summary>tests/fixtures/config-js/repomix.config.mjs (2)</summary><blockquote> <details> <summary>src/config/configSchema.ts (1)</summary> * `defineConfig` (170-170) </details> <details> <summary>src/index.ts (1)</summary> * `defineConfig` (33-33) </details> </blockquote></details> <details> <summary>tests/config/configLoad.integration.test.ts (2)</summary><blockquote> <details> <summary>src/config/configLoad.ts (1)</summary> * `loadFileConfig` (56-92) </details> <details> <summary>src/index.ts (1)</summary> * `loadFileConfig` (31-31) </details> </blockquote></details> <details> <summary>src/config/configLoad.ts (2)</summary><blockquote> <details> <summary>src/config/configSchema.ts (1)</summary> * `repomixConfigFileSchema` (139-139) </details> <details> <summary>src/shared/errorHandle.ts (2)</summary> * `rethrowValidationErrorIfZodError` (111-118) * `RepomixError` (6-11) </details> </blockquote></details> <details> <summary>tests/config/configLoad.test.ts (1)</summary><blockquote> <details> <summary>src/config/configLoad.ts (1)</summary> * `loadFileConfig` (56-92) </details> </blockquote></details> <details> <summary>tests/fixtures/config-js/repomix.config.js (2)</summary><blockquote> <details> <summary>src/config/configSchema.ts (1)</summary> * `defineConfig` (170-170) </details> <details> <summary>src/index.ts (1)</summary> * `defineConfig` (33-33) </details> </blockquote></details> </details> </details> <details> <summary>⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)</summary> * GitHub Check: Test (windows-latest, 20.x) * GitHub Check: Build and run (windows-latest, 22.x) * GitHub Check: Test with Bun (windows-latest, latest) * GitHub Check: claude-review </details> <details> <summary>🔇 Additional comments (17)</summary><blockquote> <details> <summary>website/client/src/ja/guide/configuration.md (1)</summary><blockquote> `68-80`: **Verify and document global configuration format support.** Please verify whether JavaScript config files are supported for global configuration and update the documentation to match the English version. The verification script provided for the English version will also confirm the global config format support for the Japanese documentation. </blockquote></details> <details> <summary>src/index.ts (1)</summary><blockquote> `33-33`: **LGTM!** The re-export of `defineConfig` is correctly placed in the Config section alongside other configuration exports. This makes the helper available to users importing from the main package. </blockquote></details> <details> <summary>tests/fixtures/config-js/repomix.config.js (1)</summary><blockquote> `1-12`: **LGTM!** This ES Module test fixture correctly demonstrates the use of `defineConfig` with a typical configuration structure. The relative import path is appropriate for test fixtures, and the configuration includes both output and ignore settings for comprehensive testing. </blockquote></details> <details> <summary>src/config/configSchema.ts (1)</summary><blockquote> `169-170`: **LGTM!** The `defineConfig` helper follows the established pattern used by projects like Vite and Vitest. This identity function provides TypeScript type safety and IDE autocomplete for configuration files without runtime overhead. </blockquote></details> <details> <summary>tests/fixtures/config-js/repomix.config.mjs (1)</summary><blockquote> `1-11`: **LGTM!** This `.mjs` test fixture correctly demonstrates ES Module config support with the explicit `.mjs` extension. The different output filename and ignore pattern help distinguish this test case from other JS config variants. </blockquote></details> <details> <summary>tests/fixtures/config-js/repomix-dynamic.config.js (1)</summary><blockquote> `1-13`: **LGTM!** This fixture excellently demonstrates one of the key benefits of JavaScript configuration: dynamic value generation. The runtime timestamp in the `filePath` directly addresses the PR objective of supporting timestamp suffixes, and the format matches the examples in the documentation. </blockquote></details> <details> <summary>tests/fixtures/config-js/repomix.config.cjs (1)</summary><blockquote> `1-9`: **LGTM!** This CommonJS fixture appropriately tests `.cjs` file support. By using `module.exports` directly without `defineConfig`, it confirms that the helper is optional and that plain CommonJS exports are supported. The `'plain'` output style provides useful variation for test scenarios. </blockquote></details> <details> <summary>website/client/src/en/guide/configuration.md (1)</summary><blockquote> `68-80`: **Document supported global configuration file formats** Global config loader only resolves `repomix.config.json5`, `repomix.config.jsonc` and `repomix.config.json`; JavaScript files (`.js`, `.mjs`, `.cjs`) are not supported. Update `configuration.md` to list these extensions and note that JS formats aren’t supported. </blockquote></details> <details> <summary>README.md (2)</summary><blockquote> `1013-1027`: **LGTM! Clear documentation of dynamic config capabilities.** The JavaScript config example effectively demonstrates the key features: - TypeScript IDE support via `defineConfig` - Dynamic timestamp generation for file naming (addresses issue #870) - Runtime configuration flexibility --- `1050-1141`: **Comprehensive configuration documentation.** The options table and JSON5 example provide clear guidance for all configuration scenarios while maintaining backward compatibility with existing JSON configs. </blockquote></details> <details> <summary>src/config/configLoad.ts (3)</summary><blockquote> `19-26`: **Config file priority order is well-designed.** The priority order (JS variants → JSON5 → JSONC → JSON) provides a good balance between flexibility and compatibility. JavaScript configs enable dynamic values as documented in the README. --- `94-124`: **Solid implementation with proper cross-platform support.** The dynamic import approach using `pathToFileURL` ensures Windows compatibility. The `module.default || module` fallback correctly handles both ESM (`export default`) and CommonJS (`module.exports`) patterns. One consideration: Node.js caches dynamically imported modules. If users modify their JS config and re-run Repomix in watch mode or long-running processes, they may not see changes without restarting. This is unlikely to be an issue for typical CLI usage but worth documenting if Repomix adds watch mode or daemon functionality. --- `116-118`: **Improved error messaging for multi-format support.** The generic "Invalid syntax" message appropriately covers both JavaScript and JSON parsing errors, providing clearer feedback to users regardless of config file format. </blockquote></details> <details> <summary>tests/config/configLoad.integration.test.ts (1)</summary><blockquote> `1-60`: **Comprehensive integration test coverage for JS config formats.** The test suite effectively validates: - ESM default exports (.js) - ES modules (.mjs) - CommonJS modules (.cjs) - Dynamic runtime values (timestamps) The regex pattern `^output-\d{4}-\d{2}-\d{2}T\d{2}-\d{2}-\d{2}\.xml$` correctly validates the ISO timestamp format used in the dynamic config example. </blockquote></details> <details> <summary>tests/config/configLoad.test.ts (3)</summary><blockquote> `54-76`: **Correctly updated mocks for expanded config discovery.** The mock sequence now accurately reflects the priority order: checking all JS variants (.js, .mjs, .cjs) before falling back to JSON variants, for both local and global config locations. --- `152-187`: **Priority tests correctly reflect new discovery order.** The tests now verify that: 1. JavaScript configs (.js, .mjs, .cjs) are checked first 2. JSON5 takes precedence over JSONC and JSON 3. The correct number of file system checks occur (line 186: 4 checks = 3 JS variants + 1 JSON5 match) --- `92-97`: **Error message expectation updated appropriately.** The test now expects "Invalid syntax" instead of "Invalid JSON5", which correctly reflects the generic error handling for all config file formats (JS, JSON5, JSONC, JSON). </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
Code Review - PR #886This PR adds TypeScript and JavaScript configuration file support with a defineConfig helper. Overall, this is a high-quality implementation that provides a flexible solution. Here is my detailed feedback: Strengths
Code Qualitysrc/config/configLoad.ts:108-112 - Good use of jiti for TypeScript with proper config (moduleCache: false, interopDefault: true) src/config/configLoad.ts:113-118 - Dynamic imports with proper fallback and pathToFileURL for Windows compatibility src/config/configSchema.ts:170 - Simple elegant defineConfig as identity function Suggestions
SecurityDynamic imports are secure - paths resolved via path.resolve() preventing traversal, only user configs loaded, Zod validation applied jiti package (v2.6.1) is well-maintained by Nuxt team with no known vulnerabilities PerformanceBundle size increase is reasonable, TS compilation overhead minimal (one-time), moduleCache: false prevents memory leaks TestingUnit tests properly updated for new priority order (6 additional checks) DocumentationComprehensive updates with clear examples in both English and Japanese Final AssessmentHigh-quality PR that significantly improves configuration flexibility. Well-structured, properly tested, thoroughly documented. Recommendation: APPROVE with minor suggestions Great work addressing issue #870 with a more flexible solution! |
PR Review: JavaScript/TypeScript Config SupportThis is an excellent implementation that adds much-needed flexibility to Repomix's configuration system. The code is well-structured, thoroughly tested, and follows the project's best practices. Here's my detailed review: 🎉 Strengths1. Clean Architecture & Design
2. Excellent Developer Experience
3. Thorough Testing
4. Implementation Quality
🔍 Code Quality ObservationsWell-Implemented Details
const getFileExtension = (filePath: string): string => {
const match = filePath.match(/\.(ts|mts|cts|js|mjs|cjs|json5|jsonc|json)$/);
return match ? match[1] : '';
};Simple, effective, and handles all supported formats.
const jiti = createJiti(import.meta.url, {
moduleCache: false, // Disable cache to avoid issues in tests
interopDefault: true, // Automatically use default export
});The comments explain the rationale - good practice.
config = module.default || module;Handles both default exports and named exports gracefully. 🐛 Potential Issues & Suggestions1. Security Consideration (Minor)Location: The implementation uses dynamic imports and jiti to load user-provided config files, which means arbitrary code execution. This is acceptable for a development tool where users control their config files, but worth documenting. Recommendation: Consider adding a note in the security documentation or README about this, similar to how other tools (Vite, ESLint) handle it. 2. Error Handling Enhancement (Suggestion)Location: The error handling is good, but TypeScript/JavaScript config files might throw different types of errors (module not found, syntax errors, runtime errors during evaluation). Current code: if (error instanceof SyntaxError) {
throw new RepomixError(`Invalid syntax in config file ${filePath}: ${error.message}`);
}Suggestion: Consider adding more specific error cases:
Example: if (error instanceof SyntaxError) {
throw new RepomixError(`Invalid syntax in config file ${filePath}: ${error.message}`);
}
if (error.code === 'ERR_MODULE_NOT_FOUND') {
throw new RepomixError(`Config file imports a module that cannot be found: ${error.message}`);
}3. Test Coverage Gap (Minor)Location: The integration tests are excellent, but missing a few edge cases:
Suggestion: Add test cases like: test('should handle config without defineConfig wrapper', async () => {
// Test raw object export
});
test('should throw clear error for invalid syntax in TS config', async () => {
// Test error messaging
});4. Performance Consideration (Very Minor)Location: Creating a new jiti instance for each config load with Current: Suggestion: Consider using const jiti = createJiti(import.meta.url, {
moduleCache: process.env.NODE_ENV !== 'test',
interopDefault: true,
});5. Documentation Enhancement (Minor)The documentation is excellent overall, but could be enhanced with:
📊 Test ResultsBased on the PR checklist:
Note: I couldn't run the tests directly due to permissions, but the test structure looks solid. 🔐 Security ReviewAssessment: ✅ No security issues identified
🚀 Performance ReviewAssessment: ✅ Performance impact minimal
✨ Best Practices AdherenceChecking against CLAUDE.md guidelines: ✅ Coding Guidelines:
✅ Dependencies & Testing:
✅ Commit Message:
📝 Final RecommendationsHigh Priority
Medium Priority
Low Priority (Nice to Have)
🎯 VerdictRecommendation: ✅ Approve and Merge This PR is well-implemented, thoroughly tested, and provides significant value to users. The code quality is excellent, follows all project conventions, and the documentation is comprehensive. The minor suggestions above are optional enhancements that could be addressed in follow-up PRs if desired. Great work! This is exactly the kind of developer experience improvement that makes tools delightful to use. 🎉 Review conducted using repository's CLAUDE.md guidelines and best practices |
PR Review: TypeScript/JavaScript Config File SupportThank you for this well-implemented feature! This is a valuable addition that provides excellent developer experience. Here is my detailed review: ✅ Strengths
🔍 Issues and Concerns1. Module Cache Configuration (src/config/configLoad.ts:114)The moduleCache is set to false globally. This affects production code to work around test issues. While this ensures config changes are always picked up, consider if this is the desired behavior or if cache should be enabled in production for performance. 2. Security DocumentationThe implementation executes user-provided JavaScript/TypeScript code. While this is expected for config files, consider adding a note in documentation about only using config files from trusted sources. 3. Error Message Clarity (src/config/configLoad.ts:146-155)The catch block could provide more specific error messages for common issues like missing imports or syntax errors to improve user experience. 4. Performance Minor Issue (src/config/configLoad.ts:98-101)The regex pattern is compiled on every function call. Consider moving it to module level as a constant for minor performance improvement. 🎯 Suggestions for Enhancement
📊 Overall AssessmentRating: 8.5/10 This is a well-implemented feature with high code quality and comprehensive test coverage. The concerns raised are minor and the implementation is production-ready. Main points:
✅ Approval RecommendationApprove - The implementation is solid and ready to merge. The suggestions above are optional enhancements that could be addressed in follow-up PRs. Great work on this feature! 🎉 |
Code ReviewThis is an excellent feature addition that significantly improves the developer experience for Repomix configuration! The implementation is solid, well-tested, and follows modern best practices. ✅ Strengths1. Excellent Developer Experience
2. Clean Implementation
3. Comprehensive Testing
4. Documentation
5. Backward Compatibility
🔍 Minor Observations1. Module Cache Configuration (configLoad.ts:114)
2. Error Message Consistency (configLoad.ts:148-149)
3. Type Safety in getFileExtension (configLoad.ts:98-101)
🎯 Code Quality Assessment
🚀 Performance & Security
✅ Overall AssessmentAPPROVED - This is a high-quality PR that adds significant value to the project. The implementation is clean, well-tested, and follows the project conventions perfectly. The feature solves a real user need in #870 in a flexible and extensible way. All changes align with CLAUDE.md guidelines:
Great work! This will significantly improve the developer experience for Repomix users. 🎉 |
…neConfig helper Add support for JavaScript configuration files (.js, .mjs, .cjs) with a defineConfig helper function for better DX, similar to Vite and ESLint. **Changes:** - Add defineConfig() helper function for type-safe config definitions - Support dynamic values (timestamps, environment variables, etc.) - Prioritize JS config files over JSON formats - Update documentation (README and website) with JS config examples - Add integration tests for JS config files **Priority order:** 1. repomix.config.js/mjs/cjs 2. repomix.config.json5 3. repomix.config.jsonc 4. repomix.config.json **Benefits:** - Better IDE support with TypeScript types - Dynamic configuration based on environment - More flexible than static JSON Relates to #870
Add support for TypeScript configuration files (.ts, .mts, .cts) using jiti for better developer experience. **Changes:** - Install jiti dependency for TypeScript transpilation - Update config file priority: TS > JS > JSON - Add TypeScript config test fixtures - Add integration tests for all TS config formats - Update documentation (README and website) with TS examples - Fix existing tests to account for new priority order **Priority order:** 1. repomix.config.ts/mts/cts 2. repomix.config.js/mjs/cjs 3. repomix.config.json5 4. repomix.config.jsonc 5. repomix.config.json **Benefits:** - Full TypeScript type checking in config files - Excellent IDE autocomplete and IntelliSense - Compile-time error detection - Dynamic configuration with type safety Relates to #870
Refactor file type checking to use switch statement for better readability and maintainability. **Changes:** - Add getFileExtension helper function - Replace if-else chain with switch statement - Group file extensions by type (ts/js/json) - Add default case for unsupported formats **Benefits:** - Cleaner and more maintainable code - Easier to add new file formats in the future - Better error handling for unsupported formats
…config Add documentation about the need to install repomix as a dev dependency when using TypeScript or JavaScript configuration files with defineConfig. **Changes:** - Add installation section to README.md - Add installation section to website documentation (en/ja) - Create repomix.config.ts as an example for the project itself **Key points:** - npm install -D repomix is required for defineConfig import - This enables TypeScript type checking and IDE support - Applies to both TypeScript and JavaScript config files
Add clarifying comment that this config file uses a direct import from ./src/index.js because it's the repomix project itself, while normal users should import from 'repomix'.
d5a01f4 to
751c999
Compare
PR Review SummaryThis is an excellent feature addition that provides a significant improvement to the developer experience! The implementation is well-structured and follows best practices. ✅ Strengths
🔍 Issues Found (See Details Below)
See full detailed review in next comment... |
🔍 Detailed Issues1. Critical: Dynamic Import Cache Issues (Priority: High)Location: configLoad.ts:126-128 Issue: Using dynamic import() without cache busting can cause stale configs in development/testing. While jiti has moduleCache: false, the native dynamic import doesn't. Problem: Recommendation: Add a cache-busting query parameter:
2. Security: Code Execution Risk (Priority: Medium)Location: configLoad.ts:103-156 Issue: Loading and executing user-provided TypeScript/JavaScript files introduces code execution risks. While this is inherent to the feature, it should be documented. Recommendations:
Suggested security note for docs:
3. Error Handling: Generic Error Messages (Priority: Low)Location: configLoad.ts:146-155 Issue: When jiti or dynamic import fail, the error message could be more helpful about what went wrong, especially for users who forgot to install repomix as a dev dependency. Recommendation: Provide more context about TypeScript/JavaScript-specific errors and remind users about the installation requirement. |
4. Testing: Missing Edge Cases (Priority: Low)Missing test scenarios:
These edge cases would help ensure robustness and provide better error messages to users. 5. Code Quality: Magic Number in jiti Options (Priority: Low)Location: configLoad.ts:113-116 While the comments are good, consider extracting the jiti options to a constant for better reusability and maintainability. 🎯 Performance Considerations
📝 Documentation QualityExcellent! The documentation clearly explains:
✅ Code Style & Conventions
🔒 Security AssessmentConcerns:
Mitigations:
Final Recommendation: Approve with Minor Suggestions ✅This is a high-quality PR that adds significant value. The implementation is solid, tests are comprehensive, and documentation is excellent. The suggestions above are minor improvements rather than blockers. Action Items (Optional):
Great work on this feature! 🎉 |
Added separate examples showing how to use dynamic values (timestamps and environment variables) in TypeScript and JavaScript config files. This makes it clearer how users can implement the timestamp suffix feature requested in issue #870. Changes: - Separated basic and dynamic value examples for TypeScript config - Added environment variable example for JavaScript config - Updated CommonJS example to show timestamp usage - Improved code organization and readability
Pull Request ReviewGreat work on adding TypeScript/JavaScript config file support! This is a well-designed feature that provides excellent developer experience. Here's my detailed review: ✅ Strengths
🔍 Code Quality ObservationsDetailsSecurity ConsiderationsModule Cache Disabled (src/config/configLoad.ts:114) const jiti = createJiti(import.meta.url, {
moduleCache: false, // Disable cache to avoid issues in tests
interopDefault: true,
});
Dynamic Import Security (src/config/configLoad.ts:126-128) const fileUrl = pathToFileURL(filePath).href;
const module = await import(fileUrl);
config = module.default || module;
Edge CasesFile Extension Matching (src/config/configLoad.ts:99) const match = filePath.match(/\.(ts|mts|cts|js|mjs|cjs|json5|jsonc|json)$/);
Error HandlingConfig Loading Errors (src/config/configLoad.ts:146-155)
Test CoverageUnit Tests (tests/config/configLoad.test.ts)
Integration Tests (tests/config/configLoad.integration.test.ts)
🎯 Specific Feedback1. Type Safety EnhancementThe export const defineConfig = (config: RepomixConfigFile): RepomixConfigFile => config;This is fine and follows the pattern from Vite/ESLint. It provides type checking and IDE support without runtime overhead. 2. CommonJS Import HandlingIn
3. Documentation QualityThe documentation is comprehensive with:
One minor improvement: Consider adding a note about when config files are executed (at startup) vs when they're re-evaluated, to help users understand caching behavior. 🐛 Potential IssuesMinor: Module Cache ImpactLocation: src/config/configLoad.ts:114 moduleCache: false, // Disable cache to avoid issues in testsIssue: While this comment mentions "tests", this setting affects production too. Impact: Config files are re-transpiled on every CLI invocation. For a CLI tool that loads config once per run, this is acceptable. Recommendation: Consider clarifying the comment or documenting this behavior: moduleCache: false, // Disable cache to ensure config is always fresh and avoid test pollutionMinor: Dynamic Import CacheLocation: src/config/configLoad.ts:127 Observation: Native Recommendation: No action needed, but worth being aware of for future enhancements. 📊 Test Coverage Assessment
🚀 Performance Considerations
🔐 Security Assessment
📝 Suggestions for Future Enhancements
✅ Final RecommendationAPPROVE - This is a high-quality implementation that:
The code is production-ready. All identified points are minor observations rather than blocking issues. Great work! 🎉 |
Changed "Compile-time error detection" to "Real-time error detection while editing" to accurately reflect that type checking happens in the IDE, not during Repomix execution. Since jiti loads TypeScript files at runtime, compile-time checks are not performed automatically - type errors are only caught in the IDE or when manually running tsc. This provides a more accurate description of the actual developer experience.
|
@coderabbitai review |
|
/gemini review |
🧪 Testing & Security AnalysisTest CoverageWell Covered:
The integration tests are comprehensive and follow good testing practices. Security ReviewNo security concerns identified. The implementation:
Performance ImpactAcceptable for CLI tool usage:
Overall performance is appropriate for a command-line tool. |
📋 Additional RecommendationsBefore Merge:
Future Enhancement Ideas:
📚 Related to Issue #870This solution is better than the requested timestamp suffix because it:
Great work choosing a more general and powerful solution! 🎉 |
Pull Request ReviewThis is an excellent addition to Repomix! The TypeScript/JavaScript config file support provides a much better developer experience. The implementation is well-structured, thoroughly tested, and follows the project guidelines. Strengths
Code Quality ObservationsError Handling: The getFileExtension function (src/config/configLoad.ts:98-101) returns empty string for unsupported types, handled by switch default. This is acceptable. Jiti Configuration: Good choices - moduleCache: false ensures fresh loads, interopDefault: true handles default exports well. Test Organization: Excellent separation of fixtures into config-js and config-ts directories. Performance: Sequential file existence checking is appropriate for startup. Jiti uses esbuild which is fast. Security: Safe use of jiti for user-controlled config files, standard approach used by Vite/Vitest/ESLint. Good path handling with pathToFileURL. Recommendations
Overall AssessmentCode Quality: 5/5 This PR is ready to merge! The implementation is solid, well-tested, and provides significant value. Great work! |
Moved JSON Configuration section to appear first after the priority list, before TypeScript and JavaScript sections. This provides a better user experience by showing the simplest configuration method first. Changes: - JSON Configuration now appears immediately after the format priority list - TypeScript Configuration (Recommended) follows JSON section - JavaScript Configuration comes after TypeScript - Removed duplicate JSON Configuration section at the end
Pull Request Review: TypeScript/JavaScript Config File SupportSummaryThis PR adds excellent support for TypeScript and JavaScript configuration files with a ✅ Strengths
Code Quality Observations🟡 Suggestions & Observations1. Error Handling in Config LoadingFile: The current error handling catches all errors generically. Consider adding more specific error messages for common issues: // Current approach is good, but could benefit from more specific error types
catch (error) {
rethrowValidationErrorIfZodError(error, 'Invalid config schema');
if (error instanceof SyntaxError) {
throw new RepomixError(`Invalid syntax in config file ${filePath}: ${error.message}`);
}
// Consider adding:
// - MODULE_NOT_FOUND errors (missing dependencies)
// - Permission errors (EACCES)
// - TypeScript compilation errors from jiti
}Recommendation: Consider adding more granular error messages for common failure scenarios like missing 2. Security Consideration: Dynamic Code ExecutionFile: The use of jiti to execute TypeScript/JavaScript config files introduces dynamic code execution. While this is expected for config files, consider:
Current implementation is safe for intended use, but documentation could help users understand the trust model. 3. Type Safety EnhancementFile: The export const defineConfig = (config: RepomixConfigFile): RepomixConfigFile => config;This works well! The identity function approach is perfect for providing type safety without runtime overhead. 4. Test Coverage EnhancementFile: The existing unit tests needed updates to account for the new priority order (6 new config formats before JSON). The implementation correctly updated these. Suggestion: Consider adding a test case for error scenarios:
5. Module Cache BehaviorFile: Good decision to use const jiti = createJiti(import.meta.url, {
moduleCache: false, // Disable cache to ensure fresh config loads
interopDefault: true,
});This is especially important for the MCP server use case where configs might change during the process lifetime. Well thought out! 6. Documentation StructureFile: The documentation structure is excellent, showing:
Minor suggestion: Consider adding a troubleshooting section for common issues like:
🔒 Security Assessment
Recommendation: Consider adding a brief security note in the README about config file trust. 🚀 Performance Considerations
📋 Adherence to Project Guidelines
🎯 RecommendationAPPROVE with minor suggestions This is an excellent addition to Repomix. The implementation is solid, well-tested, and provides real value to users who need dynamic configuration. The code quality is high and follows the project's conventions. Before Merging:
Great work! This significantly improves the developer experience for Repomix users. |
Reduced the JavaScript Configuration section to a single line noting it works the same as TypeScript. Removed redundant examples since the behavior and usage are identical to TypeScript configuration.
PR Review - TypeScript/JavaScript Config File SupportGreat work on adding TypeScript and JavaScript config file support! This is a well-designed feature that significantly improves the developer experience. Here's my detailed feedback: ✅ Strengths
🔍 Areas for ImprovementCode Quality & Best Practices
Testing
Documentation
Security
📊 SummaryOverall Assessment: Excellent ⭐ This PR successfully addresses issue #870 with a more flexible and powerful solution than the originally requested timestamp suffix feature. The implementation is clean, well-tested, and follows the project's coding guidelines consistently. The few suggestions above are minor improvements that would make an already strong PR even better. Key Achievements:
Recommendation: Approve with optional improvements The code is production-ready as-is. The suggested improvements are nice-to-haves that could be addressed in follow-up PRs if desired. Review completed by Claude Code Assistant |
Pull Request ReviewGreat work on this feature! This is a well-designed enhancement that provides a more flexible solution than the original timestamp suffix request. The implementation is solid overall, with comprehensive testing and documentation. Below are my detailed findings: ✅ Strengths
🔍 Issues & Suggestions1. Security Consideration: Code Execution RiskSeverity: Medium Loading and executing arbitrary TypeScript/JavaScript files introduces a security consideration. While this is common in tools like Vite and ESLint, users should be aware that config files can execute arbitrary code. Recommendation:
> **Note**: TypeScript and JavaScript config files execute code at load time. Only use config files from trusted sources.2. Error Handling in loadAndValidateConfigSeverity: Low In Current code: const jiti = createJiti(import.meta.url, {
moduleCache: false,
interopDefault: true,
});
config = await jiti.import(pathToFileURL(filePath).href);Recommendation: try {
config = await jiti.import(pathToFileURL(filePath).href);
} catch (importError) {
if (importError instanceof Error) {
throw new RepomixError(
`Failed to load TypeScript/JavaScript config from ${filePath}: ${importError.message}`
);
}
throw importError;
}This helps distinguish between import/execution errors and validation errors. 3. Test Coverage: Edge CasesSeverity: Low While the integration tests are comprehensive, consider adding tests for:
Example test: test('should handle syntax errors in TypeScript config', async () => {
await expect(
loadFileConfig(tsFixturesDir, 'repomix.config-invalid.ts')
).rejects.toThrow(/Failed to load TypeScript/);
});4. Performance: Cache ConsiderationSeverity: Low The code disables jiti's module cache ( Current: Line 118 in moduleCache: false, // Disable cache to ensure fresh config loadsQuestion: Is the config loaded multiple times during a single Repomix execution? If not, this is fine. If yes, consider whether caching could be beneficial within a single execution context. 5. Documentation: Installation RequirementSeverity: Low The README mentions that users need to Suggestion: Clarify that the installation is required for the **Installation (Optional but Recommended):**
To use TypeScript or JavaScript configuration with the `defineConfig` helper for full type safety and IDE support:
\`\`\`bash
npm install -D repomix
\`\`\`
Note: TypeScript/JavaScript configs work without this installation, but you won't get type checking or IntelliSense for the `defineConfig` helper.6. Minor: Regex Pattern in getFileExtensionSeverity: Very Low In Current: const match = filePath.match(/\.(ts|mts|cts|js|mjs|cjs|json5|jsonc|json)$/);
return match ? match[1] : '';Suggestion: Use a non-capturing group for the outer group or extract directly: const ext = filePath.match(/\.(ts|mts|cts|js|mjs|cjs|json5|jsonc|json)$/)?.[1] ?? '';
return ext;This is very minor and the current code is perfectly fine. 7. Package.json: Dependency VersionSeverity: Very Low The
Given that jiti is well-maintained and this is v2.x, 📋 Code Quality Checklist
🎯 Final RecommendationApproval: ✅ Approve with minor suggestions This is a high-quality PR that solves the user's problem elegantly. The implementation is solid, well-tested, and follows project conventions. The suggestions above are mostly minor enhancements and considerations rather than blocking issues. The most important suggestion is adding a security note in the documentation about code execution in config files. The other suggestions are nice-to-haves that can be addressed in follow-up PRs if desired. Great work! 🎉 |
Removed 'Real-time error detection while editing' as it's redundant with 'Full TypeScript type checking in your IDE' which already implies real-time error detection.
Added documentation for JSON schema validation feature that was present in the website docs but missing from README. Users can now enable auto-completion and validation in their editors by adding the $schema property to their configuration file.
Added $schema property to the example configuration to demonstrate best practice and encourage users to enable schema validation for better IDE support.
Pull Request Review - Part 1/3This is an excellent PR that adds TypeScript/JavaScript configuration file support with a defineConfig helper. The implementation is solid and well-thought-out. Strengths
|
Pull Request Review - Part 2/3Suggestions and ObservationsCode Quality
Potential Issues
Security Considerations
|
Pull Request Review - Part 3/3Test CoverageExcellent Integration Tests: The new tests comprehensively cover all file format variations, dynamic values with timestamps and environment variables, and both ESM and CJS exports. Missing Edge Case Tests: Consider adding tests for:
Unit Test Updates: Good job updating existing unit tests to account for the new file format priority order. Performance
Recommendations
Overall AssessmentCode Quality: ⭐⭐⭐⭐⭐ Excellent This is a high-quality PR that significantly improves the developer experience. The implementation follows best practices, includes comprehensive tests, and maintains backward compatibility. Great work! 🎉 Review conducted following repository CLAUDE.md guidelines |
Code Review SummaryThis is an excellent PR that adds TypeScript/JavaScript config file support with a ✅ Strengths
📝 Feedback & Suggestions1. Minor: Error handling could be more specific (Low Priority)Location: The jiti import error handling could provide more context about TypeScript compilation errors. Consider wrapping jiti.import in a try-catch to provide clearer error messages for TypeScript syntax errors. This would help users debug issues with their TS/JS config files more easily. 2. Consider: Module cache implications (Info)Location: The 3. Test Enhancement: Consider testing error scenarios (Enhancement)Location: Current integration tests cover happy paths well. Consider adding tests for:
4. Documentation: Installation requirement clarity (Minor)Location: The README mentions installing repomix as a dev dependency to use TS/JS configs. Consider clarifying that this is only needed if you want to use the defineConfig helper with type safety. TS/JS configs will still work with global repomix installation, just without type checking. 5. Code Quality: Type safety in getFileExtension (Minor)Location: Consider using a union type for better type safety instead of returning a plain string. This makes the switch statement in loadAndValidateConfig more type-safe. 🎯 Performance Considerations✅ Good: moduleCache: false prevents stale config issues 🔒 Security Assessment✅ No security concerns identified
📊 Test Coverage✅ Excellent coverage:
🚀 Performance Impact✅ Minimal:
Final Verdict✅ Approved - This is a high-quality implementation that significantly improves developer experience. The suggestions above are minor enhancements and can be addressed in follow-up PRs if desired. Great work! 🎉 |
PR Review: TypeScript/JavaScript Config SupportThis is an excellent addition to Repomix! The implementation is well-designed and follows best practices. Strengths
Code QualityStrong Points:
Minor Suggestions:
DocumentationExcellent documentation overall. Consider:
Security ReviewNo significant security concerns. Config files executing user code is expected behavior. Path handling and validation are properly implemented. Dependenciesjiti ^2.6.1 is a good choice - well-maintained, appropriate size, perfect for this use case. SummaryRecommendation: Approve with minor suggestions This is a high-quality PR that adds significant value. The suggestions above are non-blocking and can be addressed in follow-up PRs. The core implementation is solid and ready to merge. Great work! This feature will significantly improve the developer experience for Repomix users. |
|
/gemini review |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Code Review
This pull request introduces a significant enhancement by adding support for TypeScript and JavaScript configuration files, which is a great move for improving developer experience with type safety and dynamic configurations. The implementation using jiti is solid, and the changes are well-documented and thoroughly tested with new integration tests.
I've identified a couple of areas for improvement in src/config/configLoad.ts regarding code duplication and error handling. My suggestions aim to make the code more maintainable and robust. Overall, this is an excellent contribution.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
repomix.config.ts (1)
36-38: Confirm tokenCountTree documentation is complete.A past review comment noted that
tokenCountTreeneeded documentation. Reviewing the README.md changes in this PR, line 1096 documentsoutput.tokenCountTreein the configuration options table.However, the past comment specifically mentioned
website/client/src/en/guide/configuration.md. Please verify that the documentation is complete in all locations where configuration options are documented.Run the following script to check documentation coverage:
#!/bin/bash # Find all documentation files that list configuration options fd -e md -e mdx . website/ | xargs rg -l "configuration|config.*option" | head -10 # Check if tokenCountTree is documented in website docs rg -nP 'tokenCountTree' website/ -C2
🧹 Nitpick comments (2)
src/config/configLoad.ts (1)
98-101: Consider extracting the regex pattern to a constant.The file extension regex
\.(ts|mts|cts|js|mjs|cjs|json5|jsonc|json)$is specific to supported config formats. Extracting it to a named constant at module level would:
- Make the supported formats more discoverable
- Enable reuse if validation is needed elsewhere
- Clarify the relationship between this regex and
defaultConfigPathsApply this diff:
+const SUPPORTED_CONFIG_EXTENSIONS = /\.(ts|mts|cts|js|mjs|cjs|json5|jsonc|json)$/; + const getFileExtension = (filePath: string): string => { - const match = filePath.match(/\.(ts|mts|cts|js|mjs|cjs|json5|jsonc|json)$/); + const match = filePath.match(SUPPORTED_CONFIG_EXTENSIONS); return match ? match[1] : ''; };README.md (1)
1022-1028: Clarify jiti dependency installation.The documentation states "you need to install Repomix as a dev dependency" to use TypeScript/JavaScript config. While this is correct for accessing
defineConfigtypes, users don't need to worry about jiti itself since it's included as a runtime dependency in package.json.Consider adding a brief note clarifying that the jiti dependency is handled automatically, and the dev dependency is primarily needed for TypeScript types and the
defineConfighelper.Apply this diff to add clarification:
**Installation:** To use TypeScript or JavaScript configuration with `defineConfig`, you need to install Repomix as a dev dependency: ```bash npm install -D repomix
+Note: The
jitiloader for TypeScript/JavaScript support is included automatically as a runtime dependency. The dev dependency is primarily for accessing TypeScript types and thedefineConfighelper.</blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: Path: .coderabbit.yaml **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 6b1340de4e11102198c2c789533b7c96f90e5892 and 5b707f53a95def30e1efbadc5e3f14905d363c00. </details> <details> <summary>📒 Files selected for processing (3)</summary> * `README.md` (2 hunks) * `repomix.config.ts` (1 hunks) * `src/config/configLoad.ts` (3 hunks) </details> <details> <summary>🔇 Additional comments (5)</summary><blockquote> <details> <summary>src/config/configLoad.ts (2)</summary><blockquote> `108-136`: **LGTM! Clean implementation following past review feedback.** The switch statement successfully unifies loading for all script-based config files (TS/JS variants) using jiti, and handles JSON formats with JSON5. This addresses the past review comment's suggestion and ensures consistent behavior across all config file types. --- `117-121`: **moduleCache:false disables Jiti’s cache and ensures fresh config loads on each import call** </blockquote></details> <details> <summary>README.md (2)</summary><blockquote> `998-1074`: **Excellent comprehensive documentation for multi-format config support!** The updated configuration section clearly explains: - Priority order for config file discovery - TypeScript benefits (type safety, IDE support, dynamic values) - Practical examples including the dynamic timestamp pattern that addresses issue #870 - Installation requirements for TS/JS config usage The documentation provides developers with all the information needed to adopt the new config formats. --- `1053-1068`: **Dynamic values example directly addresses issue #870.** The timestamp-based filename example demonstrates how users can implement the requested timestamp suffix functionality from issue #870 using JavaScript/TypeScript config files. This is an elegant solution that provides flexibility beyond a single built-in option. The format shown (`timestamp.slice(0, 19).replace(/[:.]/g, '-')`) produces a clean `yyyy-MM-dd-HHmmss` format, which is close to the requested `yyyyMMdd-hhmmss` format from the issue. </blockquote></details> <details> <summary>repomix.config.ts (1)</summary><blockquote> `1-60`: **Excellent example of TypeScript configuration usage!** This configuration file serves dual purposes: 1. Configures the Repomix project itself 2. Provides a real-world example for users learning the new TS config format The comprehensive settings demonstrate various configuration options, including the dynamic `tokenCountTree` threshold, git integration, and custom header text. The inline comments (lines 1-3, 36-37, 51) help clarify usage patterns. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
…ge docs Add TypeScript and JavaScript configuration file documentation to all 12 language versions of the configuration guide, matching the changes made to README in PR #886. Changes include: - Add "Configuration File Formats" section explaining priority order (TS > JS > JSON) - Add "TypeScript Configuration" subsection with installation, examples, benefits, and dynamic values - Add "JavaScript Configuration" subsection - Update "Configuration File Locations" section to include all file formats - Maintain consistent translation style for each language This ensures users can learn about TypeScript/JavaScript config support in their preferred language. Languages updated: en, ja, zh-cn, zh-tw, de, fr, es, pt-br, id, vi, hi, ko
Summary
Adds support for TypeScript and JavaScript configuration files with a
defineConfighelper function for better developer experience, similar to Vite and ESLint.This provides a more flexible alternative to the requested timestamp suffix feature in #870, allowing users to implement any dynamic configuration they need.
Changes
defineConfig()helper function for type-safe config definitions.ts,.mts,.cts) using jiti.js,.mjs,.cjs)Priority Order
repomix.config.ts/.mts/.ctsrepomix.config.js/.mjs/.cjsrepomix.config.json5repomix.config.jsoncrepomix.config.jsonExample Usage
TypeScript (Recommended)
JavaScript
CommonJS
Benefits
Test plan
npm run lintnpm run testRelated Issue
Closes #870
Instead of adding a single timestamp suffix option, this implementation provides a more general solution that allows users to: