change!: split entry points into client / node #156
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe pull request introduces a restructuring of the Changes
Sequence DiagramsequenceDiagram
participant App as Application
participant Client as vitepress-openapi/client
participant OpenAPI as OpenAPI Instance
participant Theme as Theme Configuration
App->>Client: Import modules
Client->>OpenAPI: Create instance with optional defaults
Client->>Theme: Initialize configuration
Theme-->>Client: Return theme settings
Client->>App: Provide enhanced functionality
Possibly related PRs
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (27)
docs/.vitepress/config.mts(1 hunks)docs/.vitepress/theme/components/sandbox/Sandbox.vue(1 hunks)docs/.vitepress/theme/components/theme/ThemeConfig.vue(1 hunks)docs/.vitepress/theme/components/theme/ThemeConfigPopover.vue(0 hunks)docs/.vitepress/theme/index.ts(1 hunks)docs/composables/usePlayground.md(1 hunks)docs/composables/useTheme.md(1 hunks)docs/customizations/i18n.md(2 hunks)docs/customizations/operation-badges.md(1 hunks)docs/customizations/parts/code-samples-example.md(1 hunks)docs/customizations/parts/operation-badges-example.md(1 hunks)docs/customizations/parts/operation-tags-slot-example.md(1 hunks)docs/examples/[exampleSlug].md(1 hunks)docs/guide/getting-started.md(7 hunks)docs/sidebar/sidebar-items.md(3 hunks)docs/tests/[testSlug].md(1 hunks)package.json(1 hunks)src/client.ts(1 hunks)src/composables/useOpenapi.ts(1 hunks)src/composables/usePaths.ts(1 hunks)src/composables/useSidebar.ts(7 hunks)src/index.ts(0 hunks)src/lib/createOpenApiInstance.ts(1 hunks)src/lib/prepareOpenAPI/generateMissingTags.ts(2 hunks)src/lib/prepareOpenAPI/prepareOpenAPI.ts(2 hunks)test/lib/prepareOpenAPI/generateMissingTags.test.ts(5 hunks)vite.config.ts(1 hunks)
💤 Files with no reviewable changes (2)
- docs/.vitepress/theme/components/theme/ThemeConfigPopover.vue
- src/index.ts
🔇 Additional comments (27)
src/lib/createOpenApiInstance.ts (1)
8-15: LGTM!The addition of optional parameters
defaultTaganddefaultTagDescriptionenhances the configurability ofcreateOpenApiInstance. Implementation looks correct.vite.config.ts (1)
11-14: Verify the entry point paths and their exports.The split into client/node entry points looks good, but we should ensure that each entry point exports the correct modules.
✅ Verification successful
Entry point exports are properly separated and aligned with their purposes
The client bundle exports UI-related composables and code generation utilities, while the node bundle focuses on core functionality and navigation. The shared OpenApi class is correctly exported in both bundles.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check exports in both entry points echo "Checking client exports..." ast-grep --pattern 'export { $$$ }' src/client.ts echo "Checking node exports..." ast-grep --pattern 'export { $$$ }' src/index.tsLength of output: 1183
docs/.vitepress/theme/index.ts (1)
1-1: Verify all import paths are updated consistently.The import path has been updated to use the new client subpath. We should verify that all other imports in the codebase are updated consistently.
✅ Verification successful
Import path update verified - no other imports found
The import in docs/.vitepress/theme/index.ts is the only instance of importing from vitepress-openapi in the codebase. No consistency issues to address.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Find any remaining direct imports that need updating rg "from 'vitepress-openapi'" --type tsLength of output: 47
Script:
#!/bin/bash # Search for any mention of vitepress-openapi package rg "vitepress-openapi" --type ts -A 1 # Also search for any import statements in the docs directory fd . docs -e ts -x grep -l "import.*from.*vitepress-openapi"Length of output: 287
src/composables/usePaths.ts (2)
7-8: LGTM! Good use of optional parameters.The new parameters are properly typed and maintain backward compatibility.
Also applies to: 11-12
14-21: Verify error handling for invalid tag values.The OpenApi initialization looks good, but we should ensure proper error handling for invalid tag values.
src/lib/prepareOpenAPI/generateMissingTags.ts (1)
3-11: Good refactoring to remove theme dependency.The function signature change improves maintainability by removing the theme dependency and providing explicit parameters.
src/lib/prepareOpenAPI/prepareOpenAPI.ts (2)
6-14: LGTM! Well-structured parameter object pattern.The change to use a parameter object pattern with optional parameters improves the function's extensibility while maintaining backward compatibility.
31-31: LGTM! Consistent parameter passing.The update to generateMissingTags call correctly passes all parameters from the new signature.
test/lib/prepareOpenAPI/generateMissingTags.test.ts (1)
13-13: LGTM! Tests updated consistently.All test cases have been properly updated to use the new parameter object pattern while maintaining comprehensive coverage of functionality.
Also applies to: 27-27, 40-40, 60-60, 72-72
src/composables/useOpenapi.ts (1)
50-54: LGTM! Proper integration with theme configuration.The update correctly passes optional parameters from the theme configuration while maintaining type safety.
docs/.vitepress/theme/components/sandbox/Sandbox.vue (1)
4-4: Verify consistent import path updates across the codebase.The import path has been updated to use the new client entry point.
Let's verify that all client-side imports have been consistently updated:
✅ Verification successful
Import paths are correctly organized based on functionality
The import paths are consistently used across the codebase with a clear separation:
vitepress-openapi/clientfor UI components and client-side functionalityvitepress-openapifor server-side and data operations🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining imports from the old path rg "from 'vitepress-openapi'" --type ts --type vue # Search for new client imports to ensure consistency rg "from 'vitepress-openapi/client'" --type ts --type vueLength of output: 180
Script:
#!/bin/bash # Search for any imports from vitepress-openapi with surrounding context echo "=== Old import pattern ===" rg -A 2 "from ['\"](vitepress-openapi)['\"]" echo -e "\n=== New client import pattern ===" rg -A 2 "from ['\"](vitepress-openapi/client)['\"]" echo -e "\n=== Any other vitepress-openapi imports ===" rg -A 2 "from ['\"](vitepress-openapi/.*)['\"]"Length of output: 10036
docs/.vitepress/config.mts (1)
240-247: LGTM! Proper alias configuration for the new client entry point.The conditional alias configuration correctly handles both production and development environments, with proper path resolution for the new client module.
Let's verify the path resolution:
✅ Verification successful
✅ Path resolution verified - both entry points exist
The alias configuration correctly maps to existing files:
src/index.tsfor main entry pointsrc/client.tsfor client entry point🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify the existence of client entry point and its imports fd -t f "index.(ts|js|mts|mjs)" src/ fd -t f "client.(ts|js|mts|mjs)" src/Length of output: 424
docs/.vitepress/theme/components/theme/ThemeConfig.vue (1)
2-2: LGTM! Proper import from the new client entry point.The import statement has been correctly updated to use the new client module, consolidating related imports from the same path.
docs/customizations/parts/operation-badges-example.md (1)
3-3: LGTM! Consistent import path update.The import statement has been correctly updated to use the new client module, maintaining consistency with other files.
docs/customizations/parts/operation-tags-slot-example.md (1)
3-3: LGTM! Consistent import path update with proper consolidation.The import statement has been correctly updated to use the new client module, consolidating related imports from the same path.
docs/tests/[testSlug].md (1)
10-10: Verify the new client import path.The import path change aligns with the module split objective.
Let's verify the new import path exists:
✅ Verification successful
Import path verification successful
The
useThemeimport from 'vitepress-openapi/client' is correctly configured and exported from the client entry point.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify the client module exports useTheme rg -l "export.*useTheme" "src/client.ts"Length of output: 54
Script:
#!/bin/bash # Check the actual export of useTheme rg "export.*useTheme" "src/client.ts" -A 2Length of output: 177
docs/examples/[exampleSlug].md (1)
10-10: LGTM! Import path change is consistent.The update to use the client module is consistent with the module split strategy.
docs/composables/usePlayground.md (1)
8-8: Documentation accurately reflects new import path.The example code has been properly updated to use the new client module path.
Verify the usePlayground export:
✅ Verification successful
Export chain verified: usePlayground is correctly exported and documented
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify the client module exports usePlayground rg -l "export.*usePlayground" "src/client.ts"Length of output: 59
Script:
#!/bin/bash # Check the actual export statement and implementation rg "export.*usePlayground" "src/client.ts" -A 5Length of output: 391
Script:
#!/bin/bash # Verify source file exists and exports usePlayground rg "export.*function usePlayground" "src/composables/usePlayground.ts" -A 1Length of output: 199
docs/customizations/parts/code-samples-example.md (1)
3-3: Verify multiple exports from client module.The import combines multiple functions from the client module.
Verify both exports exist in client module:
✅ Verification successful
Both exports are correctly available from the client module
Both
useThemeandgenerateCodeSamplefunctions are properly exported through the client module, making the import statement valid.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify both functions are exported from client rg -l "export.*\{.*generateCodeSample.*useTheme" "src/client.ts"Length of output: 64
Script:
#!/bin/bash # Search for individual exports and definitions echo "=== Searching for useTheme ===" rg "export.*useTheme" -A 2 ast-grep --pattern "export function useTheme" echo -e "\n=== Searching for generateCodeSample ===" rg "export.*generateCodeSample" -A 2 ast-grep --pattern "export function generateCodeSample" echo -e "\n=== Searching for potential re-exports from client.ts ===" rg "export.*from" src/client.tsLength of output: 3011
docs/customizations/operation-badges.md (1)
44-44: Verify comprehensive client module exports.The import includes core functionality (theme, useTheme) and localization support.
Verify all required exports exist:
✅ Verification successful
All required exports are available in the client module
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify the client module exports all required elements rg -l "export.*\{.*locales.*theme.*useTheme" "src/client.ts"Length of output: 60
Script:
#!/bin/bash # Search for individual exports echo "=== Searching for locales export ===" rg "export.*locales" -A 2 echo "=== Searching for theme export ===" rg "export.*theme" -A 2 echo "=== Searching for useTheme export ===" rg "export.*useTheme" -A 2 # Use ast-grep to find export declarations echo "=== AST-based export search ===" ast-grep --pattern 'export { $$ }'Length of output: 1088
package.json (1)
29-30: Verify compatibility with build toolsThe main/module fields now point to node-specific builds. Ensure this doesn't affect build tools or bundlers that rely on these fields.
docs/customizations/i18n.md (1)
12-12: Import path updated correctlyThe import statement has been properly updated to use the new client submodule.
docs/sidebar/sidebar-items.md (1)
23-23: Import paths consistently updatedAll import statements have been correctly updated to use the new client submodule across multiple examples.
Also applies to: 63-63, 103-103
docs/guide/getting-started.md (3)
61-61: Documentation updated for new module structureImport statements in the basic setup examples have been correctly updated to use the client submodule.
Also applies to: 76-76
104-105: Enhanced configuration example with openapi instanceThe documentation now correctly shows how to use the useOpenapi composable with the new module structure.
Also applies to: 129-130
286-286: Markdown examples updated consistentlyImport statements in markdown examples have been properly updated to use the client submodule.
Also applies to: 308-308
docs/composables/useTheme.md (1)
8-8: Import path updated with maintained documentationThe import statement has been properly updated while preserving the detailed documentation of theme configuration options.
enzonotario
force-pushed
the
feature/client-node-entries
branch
from
d35a75e to
f3c984d
Compare
There was a problem hiding this comment.
Actionable comments posted: 9
♻️ Duplicate comments (3)
src/lib/prepareOpenAPI/generateMissingTags.ts (1)
31-31: 🧹 Nitpick (assertive)Consider adding validation for defaultTagDescription
While the implementation is correct, consider adding validation to ensure defaultTagDescription is a string.
- description: defaultTagDescription, + description: typeof defaultTagDescription === 'string' ? defaultTagDescription : '',src/client.ts (1)
34-34: 🧹 Nitpick (assertive)Avoid using 'any' type for the 'i18n' instance.
Using
anydefeats the purpose of TypeScript's type checking. Consider properly typing thei18ninstance.Apply this diff:
- const i18n: any = VueI18n.createI18n({ + const i18n = VueI18n.createI18n({src/composables/useSidebar.ts (1)
58-59: 🧹 Nitpick (assertive)Enhance the error message when OpenAPI spec is missing.
Provide a more descriptive error message to help developers understand the issue and how to fix it.
Apply this diff:
if (!spec) { - throw new Error('OpenAPI spec is not provided.') + throw new Error('OpenAPI specification is required but was not provided to useSidebar(). Please provide a valid spec.') }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (27)
docs/.vitepress/config.mts(1 hunks)docs/.vitepress/theme/components/sandbox/Sandbox.vue(1 hunks)docs/.vitepress/theme/components/theme/ThemeConfig.vue(1 hunks)docs/.vitepress/theme/components/theme/ThemeConfigPopover.vue(0 hunks)docs/.vitepress/theme/index.ts(1 hunks)docs/composables/usePlayground.md(1 hunks)docs/composables/useTheme.md(1 hunks)docs/customizations/i18n.md(2 hunks)docs/customizations/operation-badges.md(1 hunks)docs/customizations/parts/code-samples-example.md(1 hunks)docs/customizations/parts/operation-badges-example.md(1 hunks)docs/customizations/parts/operation-tags-slot-example.md(1 hunks)docs/examples/[exampleSlug].md(1 hunks)docs/guide/getting-started.md(7 hunks)docs/sidebar/sidebar-items.md(3 hunks)docs/tests/[testSlug].md(1 hunks)package.json(1 hunks)src/client.ts(1 hunks)src/composables/useOpenapi.ts(1 hunks)src/composables/usePaths.ts(1 hunks)src/composables/useSidebar.ts(7 hunks)src/index.ts(0 hunks)src/lib/createOpenApiInstance.ts(1 hunks)src/lib/prepareOpenAPI/generateMissingTags.ts(2 hunks)src/lib/prepareOpenAPI/prepareOpenAPI.ts(2 hunks)test/lib/prepareOpenAPI/generateMissingTags.test.ts(5 hunks)vite.config.ts(1 hunks)
💤 Files with no reviewable changes (2)
- src/index.ts
- docs/.vitepress/theme/components/theme/ThemeConfigPopover.vue
🔇 Additional comments (22)
src/lib/createOpenApiInstance.ts (2)
15-17: LGTM: Parameters properly forwardedThe parameters are correctly forwarded to
prepareOpenAPIwhile maintaining the original spec in the return value.
8-9: Breaking change: New optional parameters addedThe addition of
defaultTaganddefaultTagDescriptionparameters is a breaking change that needs to be documented in the changelog and migration guide.Please ensure all consumers of this function are updated to handle these new parameters. Let's verify the usage:
Also applies to: 12-13
src/composables/usePaths.ts (1)
7-8: LGTM: Consistent parameter handlingThe optional parameters match the pattern established in
createOpenApiInstance, maintaining consistency across the codebase.Also applies to: 11-12
src/lib/prepareOpenAPI/generateMissingTags.ts (1)
3-11: LGTM: Well-structured parameter objectThe function signature change to use an object parameter with defaults is a good practice for maintainability.
src/lib/prepareOpenAPI/prepareOpenAPI.ts (2)
6-14: LGTM: Consistent parameter structureThe parameter structure matches the pattern used in other files, maintaining consistency across the codebase.
31-31: 🧹 Nitpick (assertive)Consider destructuring parameters
The parameter passing could be simplified for better readability.
- spec = generateMissingTags({ spec, defaultTag, defaultTagDescription }) + spec = generateMissingTags({ spec, defaultTag, defaultTagDescription })Likely invalid or redundant comment.
vite.config.ts (1)
16-16: Document the breaking change in output file naming convention.The change in the output file naming pattern from
vitepress-openapi.${format}.jstovitepress-openapi.${entryName}.${format}.jsis a breaking change that needs to be documented. Please make sure to:
- Add documentation about the output file naming convention in the getting started guide.
- Document this as a breaking change if upgrading from a previous version.
- Include migration steps if users directly reference these files.
Run the following script to check if the documentation includes the new output file naming convention and mentions the breaking change:
#!/bin/bash # Description: Check for documentation of the new output file naming convention and breaking changes. # Search for mentions of the new file naming convention in markdown files. fd -e md | xargs rg 'vitepress-openapi\.\{entryName\}\.\{format\}\.js' # Search for mentions of breaking changes or migration guides. fd -e md | xargs rg -i 'breaking changes|migration guide|upgrade instructions'docs/.vitepress/theme/components/theme/ThemeConfig.vue (1)
2-2: LGTM! Imports consolidated correctly.The imports have been properly consolidated and updated to use the new client-specific module path.
docs/customizations/parts/operation-badges-example.md (1)
3-3: LGTM! Documentation example updated correctly.The import path has been properly updated in the documentation example, maintaining consistency with the new package structure.
docs/tests/[testSlug].md (1)
10-10: Verify the breaking change impact on consumers.The import path change from 'vitepress-openapi' to 'vitepress-openapi/client' represents a breaking change that will require updates from package consumers.
✅ Verification successful
Import path change is correctly implemented
The import path change for
useThemeto 'vitepress-openapi/client' is consistent across the codebase. The remaining imports from 'vitepress-openapi' are for a different function (usePaths) and appear to be intentionally using the main package path.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining old import paths that need updating rg "from 'vitepress-openapi'" -g '!node_modules'Length of output: 364
docs/examples/[exampleSlug].md (1)
10-10: Import path change is consistent.The update to import from 'vitepress-openapi/client' maintains consistency with the new package structure.
docs/composables/usePlayground.md (1)
8-8: Documentation is up to date.The example code correctly demonstrates the new import path from 'vitepress-openapi/client'.
docs/customizations/operation-badges.md (1)
44-44: LGTM! Import statement correctly updated.The import path has been updated to use the new client module, which aligns with the breaking change of splitting entry points.
docs/customizations/i18n.md (1)
12-12: LGTM! Import statements correctly updated.The import paths have been consistently updated to use the new client module throughout the file.
Also applies to: 47-47
package.json (1)
29-30: LGTM! Main and module fields updated consistently.The main and module fields have been updated to point to the node build, which is consistent with the new entry points structure.
docs/sidebar/sidebar-items.md (1)
23-23: LGTM! Import statements correctly updated.All import statements have been consistently updated to use the new client module throughout the documentation.
Also applies to: 63-63, 103-103
docs/.vitepress/config.mts (1)
240-247: LGTM! Development aliases configured correctly.The Vite configuration properly handles module resolution:
- Adds development-only aliases for both client and root package
- Maintains clean production builds without aliases
docs/guide/getting-started.md (4)
61-61: LGTM: Import path updated correctlyThe import path has been updated to use the new client-specific entry point.
76-76: LGTM: TypeScript import path updated correctlyThe TypeScript version of the import statement has been correctly updated.
104-105: LGTM: Import statements consolidated and updatedThe import statements have been properly consolidated and updated to use the new client entry point.
129-130: LGTM: TypeScript imports updated correctlyThe TypeScript version of the imports has been properly updated to use the new client entry point.
docs/composables/useTheme.md (1)
8-8: LGTM: Import path updated correctlyThe import path has been properly updated to use the new client entry point.
enzonotario
force-pushed
the
feature/client-node-entries
branch
from
f3c984d to
e31f0ec
Compare
enzonotario
force-pushed
the
feature/client-node-entries
branch
from
e31f0ec to
a0fd583
Compare
enzonotario
force-pushed
the
feature/client-node-entries
branch
from
a0fd583 to
f45f99a
Compare
There was a problem hiding this comment.
Actionable comments posted: 4
🔭 Outside diff range comments (2)
docs/customizations/parts/code-samples-example.md (1)
Line range hint
31-48: Consider extracting Bruno request generation logic.The
generateBruRequestfunction could be moved to a separate utility file for better maintainability and potential reuse.🧰 Tools
🪛 Markdownlint (0.37.0)
1-1: Element: script
Inline HTML(MD033, no-inline-html)
1-1: null
First line in a file should be a top-level heading(MD041, first-line-heading, first-line-h1)
docs/guide/getting-started.md (1)
Line range hint
44-44: Document the breaking change in the Usage section.Consider adding a note about the entry point split to help users understand and adapt to this breaking change.
Add this note at the beginning of the Usage section:
## Usage + +> **Breaking Change**: As of version 0.0.3-alpha.57, vitepress-openapi has split its entry points into `client` and `node` modules. The examples below use the new `client` entry point. In your `.vitepress/theme/index.[js,ts]`, import the theme and the CSS file.
♻️ Duplicate comments (4)
src/composables/useSidebar.ts (1)
59-59: 🧹 Nitpick (assertive)Enhance the error message when OpenAPI spec is missing
Provide a more descriptive error message to help developers understand the issue and how to fix it.
Apply this diff to improve the error message:
if (!spec) { - throw new Error('OpenAPI spec is not provided.') + throw new Error('OpenAPI specification is required but was not provided to useSidebar(). Please provide a valid spec.') }src/composables/usePaths.ts (1)
14-21: 🧹 Nitpick (assertive)Simplify the
prepareOpenAPIfunction callThe nested object creation can be simplified for improved readability by destructuring the parameters into a single object.
Apply this diff to simplify the code:
const openapi = OpenApi({ spec, - transformedSpec: prepareOpenAPI({ - spec, - defaultTag, - defaultTagDescription, - }), + transformedSpec: prepareOpenAPI({ spec, defaultTag, defaultTagDescription }), })src/client.ts (1)
34-34: 🛠️ Refactor suggestionAvoid using 'any' type for the 'i18n' instance.
Using
anydefeats the purpose of TypeScript's type checking. Consider properly typing thei18ninstance to enhance type safety.Apply this diff to fix the issue:
- const i18n: any = VueI18n.createI18n({ + const i18n = VueI18n.createI18n({vite.config.ts (1)
16-16:⚠️ Potential issueDocument the breaking change in output file naming convention.
The change in the output file naming pattern from
vitepress-openapi.${format}.jstovitepress-openapi.${entryName}.${format}.jsis a breaking change that needs to be documented. Please update the documentation to inform users about the new file naming convention and provide migration steps if necessary.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (27)
docs/.vitepress/config.mts(2 hunks)docs/.vitepress/theme/components/sandbox/Sandbox.vue(1 hunks)docs/.vitepress/theme/components/theme/ThemeConfig.vue(1 hunks)docs/.vitepress/theme/components/theme/ThemeConfigPopover.vue(0 hunks)docs/.vitepress/theme/index.ts(1 hunks)docs/composables/usePlayground.md(1 hunks)docs/composables/useTheme.md(1 hunks)docs/customizations/i18n.md(2 hunks)docs/customizations/operation-badges.md(1 hunks)docs/customizations/parts/code-samples-example.md(1 hunks)docs/customizations/parts/operation-badges-example.md(1 hunks)docs/customizations/parts/operation-tags-slot-example.md(1 hunks)docs/examples/[exampleSlug].md(1 hunks)docs/guide/getting-started.md(7 hunks)docs/sidebar/sidebar-items.md(3 hunks)docs/tests/[testSlug].md(1 hunks)package.json(3 hunks)src/client.ts(1 hunks)src/composables/useOpenapi.ts(1 hunks)src/composables/usePaths.ts(1 hunks)src/composables/useSidebar.ts(7 hunks)src/index.ts(0 hunks)src/lib/createOpenApiInstance.ts(1 hunks)src/lib/prepareOpenAPI/generateMissingTags.ts(2 hunks)src/lib/prepareOpenAPI/prepareOpenAPI.ts(2 hunks)test/lib/prepareOpenAPI/generateMissingTags.test.ts(5 hunks)vite.config.ts(1 hunks)
💤 Files with no reviewable changes (2)
- docs/.vitepress/theme/components/theme/ThemeConfigPopover.vue
- src/index.ts
🔇 Additional comments (25)
src/lib/createOpenApiInstance.ts (1)
8-13: Extension of functionality with optional parametersThe addition of
defaultTaganddefaultTagDescriptionparameters enhances the flexibility ofcreateOpenApiInstance. The implementation correctly updates the function signature and passes the parameters toprepareOpenAPI.src/lib/prepareOpenAPI/generateMissingTags.ts (2)
3-11: LGTM! Parameter restructuring improves extensibility.The change to use an object parameter with optional fields makes the function more maintainable and easier to extend in the future.
31-31: Consider adding validation for defaultTagDescription.While the implementation is correct, consider adding validation to ensure defaultTagDescription is a string.
- description: defaultTagDescription, + description: typeof defaultTagDescription === 'string' ? defaultTagDescription : '',src/lib/prepareOpenAPI/prepareOpenAPI.ts (1)
31-31: LGTM! Proper parameter forwarding.The parameters are correctly forwarded to
generateMissingTags, maintaining type safety.src/composables/useOpenapi.ts (1)
50-54: LGTM! Consider documenting the new parameters.The implementation looks good with proper optional chaining for the new parameters. Consider adding JSDoc comments to document the purpose and expected values of
defaultTaganddefaultTagDescription.function addSchema({ id, spec, config }: { id: string, spec: OpenAPI.Document, config?: PartialUseThemeConfig }) { + /** + * Creates an OpenAPI instance with optional default tag configuration + * @param {Object} options + * @param {OpenAPI.Document} options.spec - The OpenAPI specification + * @param {string} [options.defaultTag] - Default tag for operations without tags + * @param {string} [options.defaultTagDescription] - Description for the default tag + */ const openapi = createOpenApiInstance({test/lib/prepareOpenAPI/generateMissingTags.test.ts (1)
76-94: LGTM! Good test coverage for new parameters.The new test case properly validates the custom default tag functionality, ensuring the new parameters work as expected.
docs/sidebar/sidebar-items.md (1)
Line range hint
1-150: Well-structured documentation with comprehensive examples.The documentation effectively demonstrates the usage of sidebar functionality with:
- Clear code examples for each use case
- Interactive previews using sandbox iframes
- Well-documented optional parameters
- Visual grid layout for better readability
docs/.vitepress/theme/components/sandbox/Sandbox.vue (1)
4-4: Ensure all import paths are consistently updated across the codebase.While the import path for
useThemehas been correctly updated tovitepress-openapi/clientin this file, there may be other files that still import directly fromvitepress-openapi. To maintain consistency and prevent potential issues, please verify that all import paths have been updated.Run the following script to identify any remaining imports that need to be updated:
docs/.vitepress/config.mts (3)
3-3: LGTM! Added i18n plugin import.The addition of the Vue i18n plugin aligns with the internationalization requirements.
242-243: LGTM! Updated module resolution for split architecture.The alias configuration correctly maps:
vitepress-openapi/clientto the client entry pointvitepress-openapito the main entry point
246-250: LGTM! Configured i18n plugin with SSR support.The Vue i18n plugin is properly configured with SSR enabled.
docs/.vitepress/theme/components/theme/ThemeConfig.vue (1)
2-2: LGTM! Updated import to use client module.Correctly imports client-side utilities from the new
vitepress-openapi/clientpath.docs/customizations/parts/operation-badges-example.md (2)
3-3: LGTM! Updated import to use client module.Correctly imports useTheme from the new client-specific path.
3-3: Documentation updates needed for import paths.Several documentation files still need to be updated with the new import paths.
docs/customizations/parts/operation-tags-slot-example.md (1)
3-3: LGTM! Updated imports to use client module.Correctly imports both DEFAULT_OPERATION_SLOTS and useTheme from the new client-specific path.
docs/tests/[testSlug].md (1)
10-10: Import path change looks good.The updated import path aligns with the new package structure, properly importing from the client entry point.
docs/examples/[exampleSlug].md (1)
10-10: Import path change looks good.The updated import path aligns with the new package structure, properly importing from the client entry point.
docs/.vitepress/theme/index.ts (1)
1-1: Consider documenting the migration path.Multiple imports are affected in this core theme file. Since this represents a breaking change, consider:
- Adding a migration guide
- Documenting the new package structure
- Explaining the rationale for client/node split
docs/customizations/parts/code-samples-example.md (1)
3-3: Import path change looks good.The updated import path aligns with the new package structure, properly importing from the client entry point.
docs/customizations/operation-badges.md (1)
44-44: LGTM! Import path correctly updated.The import statement has been properly updated to use the new client entry point.
docs/customizations/i18n.md (1)
12-12: LGTM! Import paths correctly updated.Both import statements have been properly updated to use the new client entry point.
Also applies to: 47-47
package.json (2)
20-25: LGTM! Entry points correctly split into node/client.The package exports have been properly configured to support separate node and client entry points.
67-67: Verify compatibility with vue-i18n major version update.The vue-i18n package has been updated from v9 to v11, which is a major version bump. Additionally, a new @intlify/unplugin-vue-i18n dependency has been added.
Run this script to check for breaking changes:
Also applies to: 94-94
✅ Verification successful
The upgrade to vue-i18n v11 is safe ✅
The codebase already uses the recommended Composition API mode and doesn't use any deprecated or removed features. The configuration in
src/client.tsis future-proof, and the@intlify/unplugin-vue-i18nv6.0.3 is compatible with vue-i18n v11.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check vue-i18n changelog for breaking changes gh api graphql -f query=' { repository(owner: "intlify", name: "vue-i18n-next") { releases(first: 5, orderBy: {field: CREATED_AT, direction: DESC}) { nodes { tagName description } } } }'Length of output: 7840
Script:
#!/bin/bash # Check for v-t directive and tc/tc$ usage echo "Checking for v-t directive usage..." rg "v-t" -t vue echo -e "\nChecking for tc/\$tc usage..." rg "\btc\s*\(|\$tc\s*\(" -t vue -t js -t ts echo -e "\nChecking for Legacy API mode patterns..." rg "new VueI18n|createI18n\s*\(\s*\{[^}]*legacy:\s*true" -t js -t ts echo -e "\nChecking unplugin-vue-i18n version compatibility..." rg '"@intlify/unplugin-vue-i18n":\s*"[^"]*"' package.jsonLength of output: 661
Script:
#!/bin/bash # Find i18n config and vue files echo "Finding relevant files..." fd -e vue -e js -e ts echo -e "\nChecking for v-t directive usage..." rg "v-t" -g '*.vue' echo -e "\nChecking for tc/\$tc usage..." rg "\btc\s*\(|\$tc\s*\(" -g '*.{vue,js,ts}' echo -e "\nChecking for Legacy API mode patterns..." rg "createI18n.*legacy.*true" -g '*.{js,ts}' echo -e "\nChecking i18n configuration..." rg "createI18n" -g '*.{js,ts}' -A 5Length of output: 6675
docs/guide/getting-started.md (1)
61-61: LGTM! Import paths correctly updated.All import statements have been properly updated to use the new client entry point.
Also applies to: 76-76, 104-105, 129-130, 219-219, 286-286, 308-308
docs/composables/useTheme.md (1)
8-8: LGTM! Import path correctly updated.The import statement has been properly updated to use the new client entry point.
enzonotario
force-pushed
the
feature/client-node-entries
branch
from
f45f99a to
6d884c3
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
docs/.vitepress/theme/components/sandbox/SandboxPreviewSidebar.vue (1)
Line range hint
24-61: Consider memoizing sidebar generationThe sidebar generation logic could benefit from memoization to avoid unnecessary recalculations when the spec hasn't changed.
Consider using Vue's computed properties or a memoization helper:
+import { computed } from 'vue' + +const sidebarItems = computed(() => { + if (sandboxData.sidebarItemsType.value === 'itemsByPaths') { + return sidebar.itemsByPaths({ + linkPrefix: '#', + depth: sandboxData.sidebarItemsDepth.value, + collapsible: sandboxData.sidebarItemsCollapsible.value, + }) + } + if (sandboxData.sidebarItemsType.value === 'itemsByTags') { + return sidebar.itemsByTags({ + linkPrefix: '#', + }) + } + return sidebar.generateSidebarGroups({ + linkPrefix: '#', + }) +})
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (15)
docs/.vitepress/config.mts(1 hunks)docs/.vitepress/theme/components/sandbox/Sandbox.vue(1 hunks)docs/.vitepress/theme/components/sandbox/SandboxEditor.vue(1 hunks)docs/.vitepress/theme/components/sandbox/SandboxPreview.vue(1 hunks)docs/.vitepress/theme/components/sandbox/SandboxPreviewSidebar.vue(1 hunks)docs/.vitepress/theme/components/vitepress/VPDocAsideOutline.vue(1 hunks)docs/.vitepress/theme/components/vitepress/VPSwitchAppearance.vue(1 hunks)docs/.vitepress/theme/index.ts(1 hunks)docs/.vitepress/theme/style.css(1 hunks)docs/package.json(1 hunks)docs/pages.ts(1 hunks)docs/tailwind.config.js(1 hunks)package.json(2 hunks)pnpm-workspace.yaml(1 hunks)tailwind.config.js(0 hunks)
💤 Files with no reviewable changes (1)
- tailwind.config.js
🔇 Additional comments (17)
docs/.vitepress/theme/components/vitepress/VPDocAsideOutline.vue (1)
10-10: LGTM! Type safety improvementThe explicit type import for
SandboxDataenhances type safety and makes the component's dependencies clearer.docs/.vitepress/theme/components/sandbox/SandboxEditor.vue (1)
5-5: 🧹 Nitpick (assertive)LGTM! Consider enhancing error handling
The explicit type import for
SandboxDataimproves type safety. However, the error handling could be enhanced to provide better user feedback.Consider adding a user-friendly error notification instead of just logging to console:
sandboxData.spec.value = parsed } catch (error) { - console.warn('Invalid JSON') + sandboxData.error.value = 'Invalid JSON: Please check your syntax' } finally {Likely invalid or redundant comment.
docs/.vitepress/theme/components/sandbox/SandboxPreviewSidebar.vue (1)
7-7: LGTM! Type safety improvementThe explicit type import for
SandboxDataenhances type safety and maintains consistency with other components.docs/tailwind.config.js (1)
1-15: LGTM! Well-structured Tailwind configuration.The configuration correctly sets up Tailwind CSS for the VitePress theme, with proper content paths and plugin integration.
docs/.vitepress/theme/components/sandbox/Sandbox.vue (1)
4-4: Import path updated correctly.The import path change aligns with the new package structure, maintaining the same functionality while properly utilizing the client-specific module.
pnpm-workspace.yaml (1)
1-2: LGTM! Docs directory properly integrated into workspace.Adding docs to the workspace packages enables proper isolation and dependency management.
docs/.vitepress/theme/style.css (1)
1-3: LGTM! Standard Tailwind directives properly implemented.The required Tailwind CSS directives are correctly included to enable styling functionality.
docs/.vitepress/theme/index.ts (2)
1-1: LGTM! Import path updated to use the new client entry point.The change aligns with the PR objective of splitting entry points.
6-7: LGTM! Added required CSS imports.The CSS imports ensure proper styling of components.
docs/.vitepress/theme/components/vitepress/VPSwitchAppearance.vue (1)
4-4: LGTM! Import order improved.The change improves code organization by grouping external imports first.
docs/package.json (2)
19-19: LGTM! Using workspace dependency for vitepress-openapi.The workspace dependency ensures the documentation uses the local package during development.
25-36: Verify compatibility of dependency versions.Several dependencies have versions beyond my knowledge cutoff date (April 2024). Please ensure these versions are compatible and don't contain known vulnerabilities.
docs/pages.ts (1)
4-24: LGTM! Simplified spec file paths.The changes improve consistency by:
- Removing redundant './docs/' prefix
- Using consistent './public/' directory references
package.json (2)
20-28: LGTM! Properly configured dual entry points.The exports field correctly defines:
- Node entry point as the default export
- Client entry point under the '/client' subpath
- Proper type definitions for both entry points
45-46: LGTM! Updated dev scripts for documentation.The scripts properly handle the workspace setup for documentation development and building.
docs/.vitepress/theme/components/sandbox/SandboxPreview.vue (1)
5-5: Consider using a more stable import path.The import path
vitepress/dist/client/theme-default/composables/outline.jsis implementation-specific and might break across different VitePress versions. Consider using a more stable public API if available.Let's check if there's a more stable public API available:
docs/.vitepress/config.mts (1)
2-2: Verify the impact of removed path resolution.The removal of the path resolution alias might affect how the package is resolved during development. Please ensure that the package exports in
package.jsonare properly configured to handle both production and development environments.Let's verify the package exports configuration:
Description