feat: add uni-ku-root plugin
#72
Conversation
WalkthroughThe changes in this pull request involve the addition of a new plugin entry for Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
template/plugin/root/vite.config.js.data.mjs (1)
1-1: Add parameter validation foroldData.Consider adding validation to ensure
oldDataandoldData.pluginsexist to prevent runtime errors.export default function getData({ oldData }) { + if (!oldData?.plugins) { + throw new Error('oldData.plugins is required') + }src/question/plugin/choices.ts (1)
41-43: Consider using a more specific value identifier.The current value
'root'is quite generic. Consider using a more descriptive value like'uni-ku-root'or'virtual-root'to:
- Maintain consistency with the package name
- Avoid potential naming conflicts with future plugins
- Make the configuration more self-documenting
{ title: rgb(146, 220, 210)('uni-ku-root'), - value: 'root', + value: 'uni-ku-root', description: '模拟虚拟根组件(支持SFC的App.vue)', },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
src/question/plugin/choices.ts(1 hunks)template/plugin/root/package.json(1 hunks)template/plugin/root/vite.config.js.data.mjs(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- template/plugin/root/package.json
🔇 Additional comments (2)
template/plugin/root/vite.config.js.data.mjs (1)
9-14: 🛠️ Refactor suggestion
Review plugin injection strategy.
The current implementation has several potential issues to consider:
- It assumes a plugin with
id: 'uni'exists. Consider handling the case when it doesn't. - The root plugin is always inserted before the 'uni' plugin. Verify if this order is important for functionality.
- The spread operator might override important properties from
oldData.
#!/bin/bash
# Look for other files that might depend on plugin order
rg -l "plugins.*uni" --type js
# Check for any documentation about plugin ordering
fd -e md -e txt . -x grep -l "plugin.*order"Consider a more robust implementation:
return {
...oldData,
- plugins: oldData.plugins.flatMap(plugin =>
- plugin.id === 'uni' ? [rootPlugin, plugin] : plugin,
- ),
+ plugins: oldData.plugins.some(p => p.id === 'uni')
+ ? oldData.plugins.flatMap(plugin =>
+ plugin.id === 'uni' ? [rootPlugin, plugin] : plugin
+ )
+ : [...oldData.plugins, rootPlugin],
}src/question/plugin/choices.ts (1)
40-44: LGTM! The new plugin entry maintains consistency with existing entries.
The entry follows the established pattern with proper color coding, structure, and typing.
| const rootPlugin = { | ||
| id: 'root', | ||
| importer: `import UniRoot from '@uni-ku/root'`, | ||
| initializer: `// https://github.com/uni-ku/root | ||
| UniRoot()`, | ||
| } |
There was a problem hiding this comment.
💡 Codebase verification
Package is properly configured, but documentation could be improved
The @uni-ku/root package is correctly listed as a dependency in template/plugin/root/package.json, but there's no specific documentation about the plugin configuration. Consider adding documentation about the root plugin's purpose and configuration options.
- Add documentation in a README.md file within the
template/plugin/root/directory explaining:- The purpose of the root plugin
- Configuration options (if any)
- Usage examples
🔗 Analysis chain
Verify package availability and add documentation.
The plugin configuration looks good, but let's ensure:
- The
@uni-ku/rootpackage is properly listed in dependencies - The plugin configuration is documented
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if @uni-ku/root is listed in package.json files
rg -l "@uni-ku/root" --type json
# Look for any existing documentation about plugin configuration
fd -e md -e txt . -x grep -l "uni-ku/root"
Length of output: 173
Script:
#!/bin/bash
# Check package.json files for dependencies
fd package.json -x cat {} \; | jq -r '.dependencies, .devDependencies'
# Look for any imports or usage of uni-ku/root
rg "@uni-ku/root"
# Check for plugin documentation in markdown files
fd -e md -x cat {}
Length of output: 7406
|
哇🎊， |
我在
|
都行，看你愿意 |
https://github.com/uni-helper/create-uni/blob/main/.github/workflows/ci.yml |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
template/plugin/root/src/App.ku.vue (2)
1-9: LGTM! Consider adding English translations to comments.The template structure is well-organized and correctly implements the KuRootView component. The comments effectively communicate the placement options and constraints.
Consider adding English translations to the comments for better international accessibility:
<template> - <!-- 👇 顶级 KuRootView 👇 --> + <!-- 👇 Top-level KuRootView (顶级 KuRootView) 👇 --> <!-- <KuRootView /> --> - <!-- 👇 或内部 KuRootView，无论放置哪一个层级都被允许，但仅可有一个！👇 --> + <!-- 👇 Or internal KuRootView - can be placed at any level, but only one instance is allowed! + (或内部 KuRootView，无论放置哪一个层级都被允许，但仅可有一个！) 👇 --> <div> <KuRootView /> </div> </template>
1-9: Consider adding usage documentation.Since this is a template file demonstrating the plugin's usage, it would be helpful to add more comprehensive documentation.
Consider adding a script section with comments explaining:
- How to properly set up and use the KuRootView component
- The purpose and benefits of using a virtual root component
- Any configuration options available
- Common use cases and best practices
<script> /** * @uni-ku/root Plugin Template * * This template demonstrates the usage of KuRootView component which simulates * a virtual root component. The component can be placed either at the top level * or nested within other elements, but only one instance is allowed per application. * * Key Features: * - Virtual root component simulation * - Flexible placement options * - Single instance enforcement * * @see https://github.com/uni-ku/root for full documentation */ </script>.github/workflows/ci.yml (1)
106-106: LGTM! The CI matrix has been updated correctly.The addition of
-p rootto the plugin matrix ensures that the newuni-ku-rootplugin will be tested in combination with other plugins and configurations.Consider adding specific test cases for the root plugin's functionality:
- Add a test job that verifies the virtual root component is correctly generated
- Add tests for custom file names (
App.vueandroot.ku.vue) as discussed in PR commentsExample test job structure:
test-root-plugin: needs: build runs-on: ubuntu-latest steps: - name: Test root plugin run: | # Create project with root plugin node ./dist/outfile.cjs test-root -p root # Verify file generation test -f test-root/src/App.ku.vue # Test custom file names mv test-root/src/App.ku.vue test-root/src/root.ku.vue pnpm buildREADME.md (1)
69-69: Consider enhancing the plugin description.While the current description is clear, consider adding more details to help users understand the plugin's capabilities better:
- Mention CLI/HBX project support
- Add example use cases
- Include basic usage instructions
Example enhanced description:
-| [uni-ku-root](https://github.com/uni-ku/root) | 模拟虚拟根组件(支持SFC的App.vue) | root | +| [uni-ku-root](https://github.com/uni-ku/root) | 模拟虚拟根组件(支持SFC的App.vue)，支持CLI和HBX创建的项目。可自定义App.vue和root.ku.vue文件名。 | root |
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
.github/workflows/ci.yml(1 hunks)README.md(1 hunks)template/plugin/root/src/App.ku.vue(1 hunks)
🔇 Additional comments (2)
template/plugin/root/src/App.ku.vue (1)
1-9: Verify KuRootView import and component registration.
The template uses KuRootView but there's no visible import or component registration. Let's verify if this is handled by the plugin setup.
✅ Verification successful
Let me gather more information about the plugin setup by checking the vite config and package files.
KuRootView component is properly handled by the plugin setup
The @uni-ku/root plugin is correctly configured in both the vite config and package.json. The plugin automatically registers the KuRootView component globally, which explains why no explicit import is needed in App.ku.vue.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if KuRootView is properly imported/registered in the project setup
# Look for KuRootView import statements or component registrations
rg -l "KuRootView"
# Check vite config for plugin registration
rg -l "@uni-ku/root"
# Look for any documentation about KuRootView setup
fd -g "README*" -x cat {}
Length of output: 4320
Script:
#!/bin/bash
# Check vite.config.js for plugin setup
cat template/plugin/root/vite.config.js.data.mjs
# Check package.json for dependencies
cat template/plugin/root/package.json
Length of output: 507
README.md (1)
69-69: LGTM! Plugin entry follows the established format.
The new entry for uni-ku-root is well-structured and maintains consistency with other plugin entries in the table.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
README.md (1)
69-69: LGTM! Consider enhancing the plugin documentation.The plugin entry follows the correct format and provides basic information. However, consider enhancing the documentation with:
- Version compatibility information
- Basic usage examples
- Common configuration options
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
.github/workflows/ci.yml(1 hunks)README.md(1 hunks)template/plugin/root/src/App.ku.vue(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- template/plugin/root/src/App.ku.vue
🔇 Additional comments (1)
README.md (1)
69-69: Add example usage in the template.
Based on the PR discussion, it would be beneficial to include example code in the template folder to demonstrate how to use the plugin effectively. This would help users understand the proper implementation of the virtual root component.
Let's check if there are any example files in the template directory:
| @@ -103,7 +103,7 @@ jobs: | |||
| matrix: | |||
| flag-for-ts: ['', --ts] | |||
| flag-for-eslint: ['', -e] | |||
| flag-for-plugin: ['', -p import -p pages -p layouts -p manifest -p filePlatform -p platformModifier -p middleware -m pinia -m unocss -m uniNetwork -m uniUse -m uniPromises] | |||
| flag-for-plugin: ['', -p import -p pages -p layouts -p manifest -p filePlatform -p platformModifier -p middleware -p root -m pinia -m unocss -m uniNetwork -m uniUse -m uniPromises] | |||
There was a problem hiding this comment.
💡 Codebase verification
CI configuration needs additional test coverage for the root plugin
The current CI setup includes the root plugin in the test matrix (-p root), but there are gaps in test coverage:
- No dedicated test files exist for the root plugin functionality
- The plugin is only tested through the general build and dev process
- No specific test cases verify the
KuRootViewcomponent's behavior
Recommended actions:
- Add unit tests for the root plugin in a dedicated test file
- Include test cases for
KuRootViewcomponent's placement restrictions - Add integration tests to verify plugin initialization and registration
- Consider adding test cases for plugin configuration validation
🔗 Analysis chain
LGTM! The CI configuration properly integrates testing for the new plugin.
The addition of -p root to the test matrix ensures that the uni-ku-root plugin is tested across various configurations, including:
- Different platforms (H5 and WeChat Mini Program)
- Different development modes (build and dev)
- Various combinations with other plugins and UI frameworks
Let's verify if all necessary test scenarios are covered:
Consider adding plugin-specific test cases if none are found by the verification script.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if there are any plugin-specific test files or configurations that should be added
# Test 1: Check for plugin-specific test files
echo "Checking for plugin-specific test files..."
fd -t f "root.test" -t f "root.spec"
# Test 2: Check if the plugin is properly referenced in test configurations
echo "Checking test configurations..."
rg -l "uni-ku-root|@uni-ku/root" "test/" "tests/" "**/*.test.*" "**/*.spec.*"
Length of output: 572
Script:
#!/bin/bash
# Let's try a different approach to find test-related files and configurations
# Check for any files containing 'test' in their name
echo "Looking for test files across the repository..."
fd -t f "test"
# Search for test-related patterns in the entire codebase
echo "Searching for test-related patterns..."
rg -l "describe|test\(|it\(|expect\("
# Look specifically in template directory for root plugin files
echo "Checking template directory for root plugin..."
fd -t f . "template/plugin/root"
# Search for plugin registration or configuration patterns
echo "Searching for plugin configurations..."
rg -l "registerPlugin|createPlugin|plugin.*root"
Length of output: 806
Script:
#!/bin/bash
# Let's examine the plugin configuration and test coverage in more detail
# Check the content of vite config to understand plugin setup
echo "Examining vite config for root plugin..."
cat template/plugin/root/vite.config.js.data.mjs
# Check CI workflow file to understand test coverage
echo "Examining CI workflow..."
cat .github/workflows/ci.yml
# Look for any plugin-related test utilities or helpers
echo "Searching for plugin test utilities..."
rg -l "plugin.*test|test.*plugin"
# Check if there are any example or test cases in the root plugin template
echo "Checking root plugin template files..."
cat template/plugin/root/src/App.ku.vue
Length of output: 4905
|
uni-helper/vite-plugin-uni-components#13 这个pr应该能解决类似问题 |
|
awesome job! 等components那边的PR合并了，我一并更改代码！ |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (4)
template/plugin/root/src/App.ku.vue (2)
1-13: Add error handling and i18n supportThe script section has several areas for improvement:
- Add error handling for window.open
- Implement i18n for the toast message
- Add error handling for uni.showToast
Consider applying these improvements:
<script setup> +import { ref } from 'vue' +import type { ShowToastOptions } from '@dcloudio/uni-app' + +const GITHUB_URL = 'https://github.com/uni-ku/root' + function handleClickGithub() { if (window?.open) { - window.open('https://github.com/uni-ku/root') + try { + const newWindow = window.open(GITHUB_URL) + if (!newWindow) { + throw new Error('Popup blocked') + } + } catch (error) { + showFallbackToast() + } } else { - uni.showToast({ - icon: 'none', - title: '请使用浏览器打开', - }) + showFallbackToast() } } + +function showFallbackToast() { + const options: ShowToastOptions = { + icon: 'none', + title: t('messages.openInBrowser'), + duration: 2000, + } + uni.showToast(options).catch(error => { + console.error('Failed to show toast:', error) + }) +} </script>
25-47: Enhance styling with responsive design and dark modeThe styles could be improved with:
- Mobile-friendly adjustments
- Dark mode support
- Interactive states (hover, focus)
- Proper button reset styles
Consider enhancing the styles:
<style> .root-bar { position: fixed; bottom: 0; left: 0; width: 100%; height: 40px; background-color: #f5f5f5; display: flex; align-items: center; justify-content: center; color: #999; font-size: 14px; line-height: 40px; text-align: center; box-sizing: border-box; padding: 0 20px; + @media (max-width: 768px) { + height: 32px; + line-height: 32px; + font-size: 12px; + } + @media (prefers-color-scheme: dark) { + background-color: #1a1a1a; + color: #888; + } } + +.link-button { + background: none; + border: none; + padding: 0; + font: inherit; + cursor: pointer; +} + .color-blue { color: #409eff; cursor: pointer; + transition: color 0.2s ease; + + &:hover, &:focus { + color: #66b1ff; + } + + @media (prefers-color-scheme: dark) { + color: #5caefc; + + &:hover, &:focus { + color: #79bcff; + } + } } </style>template/UI/uni/vite.config.js.data.mjs (2)
19-28: Refactor Plugin Manipulation Logic for Improved ReadabilityThe current use of nested ternary operators and
flatMapmakes the code complex and harder to maintain. Refactoring the logic can enhance clarity and simplify future modifications.Consider the following refactored code:
const plugins = [...oldData.plugins]; if (plugins.some(plugin => plugin.id === 'autoImport')) { plugins.forEach((plugin, index) => { if (plugin.id === 'autoImport') { plugins.splice(index, 1, { id: plugin.id, importer: plugin.importer }, autoImportUniUiPlugin(hasRootPlugin)); } }); } else if (plugins.some(plugin => plugin.id === 'uni')) { plugins.forEach((plugin, index) => { if (plugin.id === 'uni') { plugins.splice(index, 0, autoImportUniUiPlugin(hasRootPlugin)); } }); } else { plugins.push(autoImportUniUiPlugin(hasRootPlugin)); } return { ...oldData, plugins, };This approach uses standard array methods to manipulate the
pluginsarray, improving readability and maintainability.
2-10: Consider HoistingautoImportUniUiPluginOutsidegetDataFunctionIf the
autoImportUniUiPluginfunction does not rely on variables scoped withingetData, you might consider moving it outside ofgetDatato avoid recreating the function on every call.Refactoring example:
const autoImportUniUiPlugin = (hasRoot) => { return { id: 'uni-ui', importer: `import { UniUIResolver } from '@uni-helper/vite-plugin-uni-components/resolvers'`, initializer: `Components({ dts: true, resolvers: [UniUIResolver(${hasRoot ? "{ exclude: 'UniKuAppRoot' }" : ''})] })`, }; }; export default function getData({ oldData }) { // ...rest of the code }This can slightly improve performance by not redefining the function on each invocation.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
template/UI/uni/vite.config.js.data.mjs(1 hunks)template/plugin/import/package.json(1 hunks)template/plugin/root/src/App.ku.vue(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- template/plugin/import/package.json
🔇 Additional comments (2)
template/UI/uni/vite.config.js.data.mjs (2)
6-8: Ensure Proper Handling of Resolver Options
When hasRoot is false, the resolver configuration might include an unnecessary comma or incorrect syntax due to the empty string. Verify that the generated initializer string is syntactically correct in both cases.
You can test the output of the initializer property for both values of hasRoot:
console.log(autoImportUniUiPlugin(true).initializer);
console.log(autoImportUniUiPlugin(false).initializer);This will help ensure that the configuration is correctly generated without syntax errors.
13-13: Verify Existence of the plugins Property in oldData
Ensure that oldData.plugins is always defined before calling .some() to prevent potential runtime errors if plugins is undefined.
Run the following script to check for definitions and usages of oldData.plugins:
This will help confirm that oldData.plugins is reliably available throughout the codebase.
| <template> | ||
| <div> | ||
| <KuRootView /> | ||
| <div class="root-bar"> | ||
| Root component By | ||
| <span class="color-blue" @click="handleClickGithub">uni-ku/root</span> | ||
| </div> | ||
| </div> | ||
| </template> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve component structure and accessibility
The template section needs improvements in several areas:
- KuRootView component import is missing
- Clickable span should be a button for accessibility
- Consider adding error boundary and loading states
Apply these changes for better accessibility and error handling:
+<script setup>
+import { KuRootView } from '@uni-ku/root'
+// ... rest of the script
+</script>
<template>
<div>
- <KuRootView />
+ <Suspense>
+ <template #default>
+ <KuRootView />
+ </template>
+ <template #fallback>
+ <div>Loading...</div>
+ </template>
+ </Suspense>
<div class="root-bar">
Root component By
- <span class="color-blue" @click="handleClickGithub">uni-ku/root</span>
+ <button
+ class="link-button color-blue"
+ @click="handleClickGithub"
+ aria-label="Open uni-ku/root GitHub page"
+ >
+ uni-ku/root
+ </button>
</div>
</div>
</template>Committable suggestion skipped: line range outside the PR's diff.
| <script setup> | ||
| function handleClickGithub() { | ||
| if (window?.open) { | ||
| window.open('https://github.com/uni-ku/root') | ||
| } | ||
| else { | ||
| uni.showToast({ | ||
| icon: 'none', | ||
| title: '请使用浏览器打开', | ||
| }) | ||
| } | ||
| } | ||
| </script> | ||
|
|
||
| <template> | ||
| <div> | ||
| <KuRootView /> | ||
| <div class="root-bar"> | ||
| Root component By | ||
| <span class="color-blue" @click="handleClickGithub">uni-ku/root</span> | ||
| </div> | ||
| </div> | ||
| </template> | ||
|
|
||
| <style> | ||
| .root-bar { | ||
| position: fixed; | ||
| bottom: 0; | ||
| left: 0; | ||
| width: 100%; | ||
| height: 40px; | ||
| background-color: #f5f5f5; | ||
| display: flex; | ||
| align-items: center; | ||
| justify-content: center; | ||
| color: #999; | ||
| font-size: 14px; | ||
| line-height: 40px; | ||
| text-align: center; | ||
| box-sizing: border-box; | ||
| padding: 0 20px; | ||
| } | ||
| .color-blue { | ||
| color: #409eff; | ||
| cursor: pointer; | ||
| } | ||
| </style> |
There was a problem hiding this comment.
💡 Codebase verification
Based on the gathered information, I can now provide the final response:
Documentation and testing improvements needed
This component is part of the uni-ku-root plugin which simulates virtual root components. Based on the repository structure and documentation:
- Add JSDoc comments to explain the component's purpose and functionality:
/** * Root component wrapper for uni-ku * Provides a fixed bottom bar with GitHub link * @component */
- Add the following to the template/plugin/root/README.md file:
- Installation instructions
- Component API documentation
- Customization examples
- Platform compatibility notes
- Create test files in template/plugin/root/tests/ directory for:
- Component rendering
- GitHub link functionality
- Platform-specific behavior
🔗 Analysis chain
Verify documentation and testing requirements
As this is a template file for the uni-ku-root plugin, please ensure:
- Add comments explaining the component's purpose and usage
- Include example customization instructions
- Add unit tests for the component
Let's check for existing documentation and tests:
Let me check the repository structure and any related documentation at the root level before making the final recommendation.
Let me check the content of the README files and package.json to understand the documentation context better.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for documentation and test files
echo "Checking for documentation..."
fd -t f "README" template/plugin/root
fd -t f "docs?" template/plugin/root
echo "Checking for test files..."
fd -t f "test|spec" template/plugin/root
echo "Checking for example usage..."
fd -t f "example" template/plugin/root
Length of output: 359
Script:
#!/bin/bash
# Check repository structure and root documentation
echo "Checking root documentation..."
fd -t f "README|docs?"
echo "Checking plugin structure..."
ls -R template/plugin/root/
echo "Checking for any inline documentation..."
rg -l "\/\*\*|\*\/|\/\/" template/plugin/root/
Length of output: 559
Script:
#!/bin/bash
# Check content of documentation and package files
echo "Checking root README content..."
cat README.md
echo -e "\nChecking template README content..."
cat src/question/template/README.md
echo -e "\nChecking package.json content..."
cat template/plugin/root/package.json
echo -e "\nChecking for comments with fixed regex..."
rg -l "(/\*|//)" template/plugin/root/
Length of output: 4751
| const autoImportUniUiPlugin = (hasRoot) => { | ||
| return { | ||
| id: 'uni-ui', | ||
| importer: `import { UniUIResolver } from '@uni-helper/vite-plugin-uni-components/resolvers'`, | ||
| initializer: `Components({ | ||
| dts: true, | ||
| resolvers: [UniUIResolver()] | ||
| resolvers: [UniUIResolver(${hasRoot ? '{exclude: \'UniKuAppRoot\'}' : ''})] | ||
| })`, | ||
| } |
There was a problem hiding this comment.
Ensure Correct Formatting of the initializer String
The initializer property within the autoImportUniUiPlugin function may generate an invalid configuration when hasRoot is false. Specifically, the resolver array could contain an empty string, leading to syntax errors.
To fix this issue, adjust the conditional expression to properly handle the absence of the exclude option:
initializer: `Components({
dts: true,
- resolvers: [UniUIResolver(${hasRoot ? '{exclude: \'UniKuAppRoot\'}' : ''})]
+ resolvers: [UniUIResolver(${hasRoot ? "{ exclude: 'UniKuAppRoot' }" : undefined })]
})`,Alternatively, you can refactor the code to build the options object separately:
const resolverOptions = hasRoot ? "{ exclude: 'UniKuAppRoot' }" : '';
initializer: `Components({
dts: true,
resolvers: [UniUIResolver(${resolverOptions})]
})`,This ensures that when hasRoot is false, the UniUIResolver is called without any arguments, preventing potential syntax issues.
Description 描述
添加模拟虚拟根组件插件 uni-ku-root
Linked Issues 关联的 Issues
close: #60
Summary by CodeRabbit
New Features
uni-ku-root, enhancing component management capabilities.@uni-ku/root, enabling additional functionalities during development.uni-ku-rootplugin and clarified Node.js version requirements for Vite.Improvements
@uni-helper/vite-plugin-uni-componentsfor potential enhancements and bug fixes.