Style/translate #258
Style/translate #258
Conversation
* fix: llm script related #234 * refactor: Remove logic to generate files for debug * refactor(llm): clean up script, add error handling, and update docs - Removed unnecessary parts in the LLM script to simplify logic - Added error handling to improve stability and prevent silent failures - Updated related documentation to reflect the revised implementation * chore: add sinon to project dependencies - Installed sinon as a regular dependency - Ensures sinon is available in runtime environment - Edited getItdocPrompt annotation * chore(lockfile): regenerate pnpm-lock.yaml to match package.json
* fix: apply header key normalized to lowercase * update expected oas.json
WalkthroughThis PR primarily translates Korean comments, descriptions, and test titles to English across configs, scripts, tests, and example apps. .npmrc is reduced to a single setting (loglevel=verbose). The Express example updates user-facing strings and OAS examples; expected oas.json reflects these changes and switches path patterns from {param} to :param for two routes. Product and cached-data example strings are updated. A functional change refines validateResponse.ts to explicitly handle comparisons when actual values are DSL fields versus primitives/objects. Other code files contain comment-only edits. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
lib/__tests__/unit/dsl/test-builders/vaildateResponse.test.ts (1)
1-1: Note: Pre-existing filename typo.The test file is named
vaildateResponse.test.ts(missing 'i'), but should bevalidateResponse.test.tsto match the module it's testing. This is a pre-existing issue, not introduced by this PR.Do you want me to open a separate issue to track renaming this file?
lib/config/getOpenAPIConfig.ts (2)
26-31: Consider adding JSDoc @returns tag.While the TypeScript signature documents the return type, adding a
@returnstag would complete the JSDoc documentation and satisfy linting rules.Apply this diff:
/** * Retrieve the title that will be applied to the generated OAS. + * @returns {string} The configured OAS title from package.json or default "API Document" */
33-41: Consider adding JSDoc @returns tag.Similar to the previous function, adding a
@returnstag would complete the JSDoc documentation.Apply this diff:
/** * Retrieve the top-level description for the generated OAS document. + * @returns {string} The configured OAS description from package.json or default message */
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (26)
.npmrc(1 hunks).vscode/settings.json(0 hunks)bin/index.ts(1 hunks)eslint.config.js(5 hunks)examples/express/__tests__/expressApp.test.js(14 hunks)examples/express/expected/oas.json(59 hunks)examples/express/expressApp.js(2 hunks)examples/express/scripts/run-tests-and-validate.js(1 hunks)examples/testframework-compatibility-test/__tests__/compatibility.test.ts(2 hunks)lib/__tests__/unit/config/logger.test.ts(1 hunks)lib/__tests__/unit/dsl/OpenAPIGenerator.test.ts(12 hunks)lib/__tests__/unit/dsl/interface/field.test.ts(1 hunks)lib/__tests__/unit/dsl/interface/header.test.ts(1 hunks)lib/__tests__/unit/dsl/test-builders/vaildateResponse.test.ts(1 hunks)lib/config/getOpenAPIConfig.ts(1 hunks)lib/config/logger.ts(4 hunks)lib/dsl/generator/OpenAPIGenerator.ts(1 hunks)lib/dsl/generator/builders/OperationBuilder.ts(0 hunks)lib/dsl/generator/builders/schema/SchemaFactory.ts(1 hunks)lib/dsl/test-builders/ResponseBuilder.ts(1 hunks)lib/dsl/test-builders/validateResponse.ts(4 hunks)pnpm-workspace.yaml(1 hunks)script/llm/examples/index.ts(3 hunks)script/llm/parser/analyzer/routeAnalyzer.ts(1 hunks)script/llm/parser/collector/routeCollector.ts(1 hunks)script/llm/parser/utils/extractValue.ts(2 hunks)
💤 Files with no reviewable changes (2)
- lib/dsl/generator/builders/OperationBuilder.ts
- .vscode/settings.json
🧰 Additional context used
🧬 Code graph analysis (9)
lib/config/getOpenAPIConfig.ts (1)
lib/config/readPackageJson.ts (1)
readItdocConfig(28-51)
lib/dsl/test-builders/ResponseBuilder.ts (1)
lib/dsl/test-builders/RequestBuilder.ts (1)
res(87-89)
lib/dsl/generator/builders/schema/SchemaFactory.ts (1)
lib/dsl/interface/field.ts (1)
isDSLField(59-60)
lib/__tests__/unit/dsl/OpenAPIGenerator.test.ts (1)
lib/dsl/index.ts (1)
HttpMethod(17-17)
lib/__tests__/unit/dsl/interface/field.test.ts (1)
lib/dsl/interface/field.ts (1)
field(44-50)
lib/dsl/test-builders/validateResponse.ts (1)
examples/express/scripts/run-tests-and-validate.js (2)
expected(55-55)actual(54-54)
examples/express/__tests__/expressApp.test.js (2)
lib/dsl/interface/itDoc.ts (1)
itDoc(21-48)lib/dsl/interface/field.ts (1)
field(44-50)
lib/__tests__/unit/dsl/test-builders/vaildateResponse.test.ts (2)
lib/dsl/test-builders/validateResponse.ts (1)
validateResponse(109-149)lib/dsl/interface/field.ts (1)
field(44-50)
lib/__tests__/unit/dsl/interface/header.test.ts (1)
lib/dsl/interface/header.ts (1)
header(21-25)
🪛 Checkov (3.2.334)
examples/express/expected/oas.json
[medium] 135-143: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
🔇 Additional comments (34)
lib/__tests__/unit/dsl/interface/field.test.ts (1)
20-51: LGTM! Clean translation to English.The test descriptions have been accurately translated to English and remain clear, grammatically correct, and properly describe the behavior being tested. The test logic is unchanged and continues to correctly validate the
field()function's behavior.lib/dsl/test-builders/validateResponse.ts (1)
35-35: LGTM! Comment translations improve code clarity.The English comments accurately describe each validation branch and make the code more accessible to international contributors.
Also applies to: 41-41, 51-51, 110-110, 116-116, 145-145
lib/__tests__/unit/dsl/test-builders/vaildateResponse.test.ts (1)
21-194: LGTM! Test translations are thorough and consistent.The test suite has been successfully translated from Korean to English:
- Test descriptions clearly convey intent
- Fixture keys updated consistently (사용자 → user, 이름 → name, 목록 → list, 데이터 → data, 항목 → items, 값 → value)
- Error message paths correctly reflect the new English keys
- Test coverage and logic remain unchanged
The translations improve maintainability and accessibility for international contributors.
eslint.config.js (1)
22-142: LGTM! English comments improve maintainability.The translation of configuration comments from Korean to English makes the codebase more accessible to international contributors without altering any ESLint rules or behavior.
script/llm/examples/index.ts (1)
22-110: LGTM! English examples enhance usability.The translation of API documentation strings, test descriptions, and field labels to English improves the developer experience for international users without modifying any test logic or DSL behavior.
lib/dsl/generator/OpenAPIGenerator.ts (1)
47-47: LGTM! Comment clarifies default security behavior.The English translation accurately describes the default security requirement configuration.
examples/express/expressApp.js (1)
204-241: LGTM! Response strings localized to English.The translation of product names and cached data content improves consistency with the English-language test suite without altering API behavior.
examples/express/scripts/run-tests-and-validate.js (1)
31-32: LGTM! Script documentation improved.The English comment clearly explains the OAS comparison logic without modifying the validation behavior.
lib/config/logger.ts (1)
21-140: LGTM! Logger documentation enhanced.The translation of inline comments to English improves code readability without affecting logging behavior, test environment detection, or output formatting.
lib/dsl/test-builders/ResponseBuilder.ts (1)
181-181: LGTM! Comment clarifies response body preference.The English translation accurately documents the logic for preferring the expected response body during validation.
lib/dsl/generator/builders/schema/SchemaFactory.ts (1)
77-98: LGTM! Schema generation logic well-documented.The English comments clearly describe the type-based schema generation flow without modifying any type checks or generator invocations.
lib/config/getOpenAPIConfig.ts (1)
19-24: LGTM! Clear and concise documentation.The English translation accurately describes the function's purpose. The implementation correctly retrieves the base URL configuration with a sensible default.
lib/__tests__/unit/dsl/OpenAPIGenerator.test.ts (6)
43-66: LGTM! Test descriptions are clear and accurate.The English translations improve readability and accurately describe the test scenarios for empty response body handling.
68-90: LGTM! Null response body test is well-documented.The test case correctly validates that null response bodies don't generate content in the OpenAPI spec.
92-113: LGTM! Clear test description for undefined body handling.The translation accurately describes the test scenario for undefined response bodies.
115-159: LGTM! Comprehensive error response test.The test thoroughly validates error object creation with clear English descriptions and assertions. The use of
anytype on line 58 is acceptable in test contexts where we're validating the structure of generated specs.
161-204: LGTM! Success response test is well-structured.The translation clearly describes the test scenario and the assertions validate that the response shape is preserved.
206-236: LGTM! Edge case test is clearly documented.The test correctly validates that when no test cases define a body for a status code, no content is created in the spec.
lib/__tests__/unit/config/logger.test.ts (2)
33-60: LGTM! Logger test descriptions are clear and professional.The English translations accurately describe the logger behavior and use appropriate test data. The test correctly validates formatted log output.
62-75: LGTM! ITDOC_DEBUG environment variable tests are well-documented.The test descriptions clearly explain the expected behavior for different ITDOC_DEBUG settings.
examples/express/expected/oas.json (5)
17-91: LGTM! API translations are clear and professional.The English translations for the signup endpoint are accurate and follow API documentation best practices. Field descriptions, summaries, and error messages are clear and concise.
427-596: LGTM! User list API documentation is comprehensive.The translations clearly describe the pagination parameters, response structure, and error conditions. Field descriptions are accurate and helpful.
641-924: LGTM! Complex order API is well-documented.The English translations accurately describe the nested order structure with customer details, items, shipping, and payment information. The examples use appropriate English values (e.g., "Hong Gil-dong", "Seoul", "Laptop").
926-1172: LGTM! Product search API has thorough documentation.The translations clearly describe all filter parameters and the complex response structure. Field descriptions are helpful and examples are realistic.
1174-1302: LGTM! System and test endpoints are clearly documented.The caching API and failure-inducing test endpoint translations are clear and accurately describe their purposes.
examples/express/__tests__/expressApp.test.js (9)
5-57: LGTM! Signup API tests are clearly documented.The English translations for test descriptions and field labels are accurate and align with the expected OAS documentation. The test scenarios comprehensively cover success and error cases.
59-97: LGTM! User lookup tests are well-structured.The test descriptions clearly explain the expected behavior for valid and invalid user IDs. Field labels are consistent with API documentation.
99-144: LGTM! Friend deletion tests cover all scenarios.The test cases thoroughly validate error conditions and successful deletion with clear English descriptions.
146-209: LGTM! User list API tests are comprehensive.The tests validate both successful retrieval and error conditions with clear field descriptions and appropriate English examples.
211-246: LGTM! Authentication tests are clearly documented.The secret API tests appropriately validate both authenticated and unauthenticated scenarios with clear descriptions.
248-333: LGTM! User update tests use appropriate localized examples.The PUT and PATCH tests use realistic English names and addresses (Hong Gil-dong, Seoul, Gangnam-daero) that make sense in context. Field descriptions are clear and consistent.
335-406: LGTM! Order creation test is comprehensive.The complex nested order structure is well-documented with clear English field descriptions and realistic product examples (Laptop, Mouse).
408-458: LGTM! Product search test validates complex query parameters.The test comprehensively covers multiple search filters with clear English descriptions and realistic product examples (Wireless Mouse, Bluetooth Keyboard).
460-517: LGTM! Caching and failure tests are clearly documented.The HTTP caching test and intentional failure test are well-described with appropriate English terminology.
| program | ||
| .name("itdoc") | ||
| .usage("A CLI tool for generating ITDOC test code using LLM") // ✅ 직접 Usage 설정 | ||
| .usage("A CLI tool for generating ITDOC test code using LLM") |
There was a problem hiding this comment.
Restore a syntax-focused usage string.
.usage should describe the command signature; changing it to narrative text now yields Usage: itdoc A CLI tool..., which breaks the help output. Keep .usage for syntax and move the sentence into .description or addHelpText.
program
.name("itdoc")
- .usage("A CLI tool for generating ITDOC test code using LLM")
+ .usage("[command] [options]")
+ .description("A CLI tool for generating ITDOC test code using LLM")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| .usage("A CLI tool for generating ITDOC test code using LLM") | |
| program | |
| .name("itdoc") | |
| .usage("[command] [options]") | |
| .description("A CLI tool for generating ITDOC test code using LLM") |
🤖 Prompt for AI Agents
In bin/index.ts around line 46, the .usage call was changed to narrative text
which causes the help output to show "Usage: itdoc A CLI tool..." instead of a
command signature; restore .usage to contain the command syntax/signature (e.g.,
the expected command name and options/arguments) and move the descriptive
sentence "A CLI tool for generating ITDOC test code using LLM" into .description
or addHelpText so the help output renders correctly.
| } | ||
| }, | ||
| "/users/{userId}": { | ||
| "/users/:userId": { |
There was a problem hiding this comment.
Critical: Invalid OpenAPI path parameter syntax.
The paths use Express routing syntax (:param) instead of OpenAPI 3.0 specification syntax ({param}):
- Line 92:
/users/:userIdshould be/users/{userId} - Line 386:
/users/:userId/friends/:friendNameshould be/users/{userId}/friends/{friendName}
OpenAPI 3.0 specification requires path parameters to be enclosed in curly braces. The colon syntax is specific to Express.js and will cause validation errors with OpenAPI tooling (validators, code generators, documentation tools like Swagger UI).
Apply this diff to fix the path syntax:
- "/users/:userId": {
+ "/users/{userId}": {- "/users/:userId/friends/:friendName": {
+ "/users/{userId}/friends/{friendName}": {Also applies to: 386-386
🤖 Prompt for AI Agents
In examples/express/expected/oas.json around lines 92 and 386, the OpenAPI paths
incorrectly use Express-style colon syntax (e.g. "/users/:userId" and
"/users/:userId/friends/:friendName"); replace those with OpenAPI parameter
syntax by changing ":param" to "{param}" so the paths become "/users/{userId}"
and "/users/{userId}/friends/{friendName}", and ensure corresponding parameter
objects (name, in: "path", required: true, schema) reference the same parameter
names.
2 participants
WIP
closed #257
Summary by CodeRabbit