feat: [grid,alert,form]use catalog to globally upgrade vite and vitest; and add mobile build config #2680
Conversation
WalkthroughThis pull request involves multiple configuration and dependency updates across various packages in the project. The changes primarily focus on updating development dependencies, modifying build configurations, and introducing new TypeScript and Vite configurations for the mobile package. The modifications include updating package.json files, introducing new configuration files like tsconfig.json and vite.config.ts, and making minor adjustments to existing code, such as changing a property declaration in the SHA256 hashing utility. Changes
Possibly related PRs
Suggested labels
Poem
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 (
|
zzcr
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
packages/mobile/package.json (1)
28-28: Consider enhancing build script configurationThe build script has been simplified to
"vite build"but might benefit from additional configuration options for different environments or build modes.Consider expanding the build script:
- "build": "vite build" + "build": "vite build", + "build:dev": "vite build --mode development", + "build:prod": "vite build --mode production"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
internals/cli/package.json(1 hunks)internals/unplugin-virtual-template/tsup.config.ts(1 hunks)package.json(1 hunks)packages/mobile/package.json(2 hunks)packages/mobile/tsconfig.json(1 hunks)packages/mobile/tsconfig.node.json(1 hunks)packages/mobile/vite.config.ts(1 hunks)packages/utils/package.json(1 hunks)packages/utils/src/crypt/sha256.ts(1 hunks)pnpm-workspace.yaml(1 hunks)
✅ Files skipped from review due to trivial changes (3)
- packages/mobile/tsconfig.node.json
- packages/mobile/tsconfig.json
- package.json
🔇 Additional comments (7)
internals/unplugin-virtual-template/tsup.config.ts (1)
7-7: Verify impact of disabled TypeScript declarations
Disabling dts generation means TypeScript declaration files (*.d.ts) won't be generated. This could impact TypeScript users of this package.
Let's check the impact:
Please clarify:
- Why was type declaration generation disabled?
- How will TypeScript support be maintained?
packages/utils/package.json (1)
24-26: Verify vite-plugin-dts compatibility with Vite 6
While moving to catalog versions for typescript and vite is good for standardization, please verify that [email protected] is compatible with Vite 6.
Let's check compatibility:
Consider:
- Updating vite-plugin-dts to a newer version that officially supports Vite 6
- Adding vite-plugin-dts to the catalog for consistent versioning
✅ Verification successful
vite-plugin-dts is compatible with Vite 6
The verification shows that vite-plugin-dts has no strict version constraints for Vite in its peer dependencies (accepts any version with *). The package version 4.3.0 should work fine with Vite 6. Additionally, there are other packages in the monorepo already using vite-plugin-dts v4.3.0 successfully.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check vite-plugin-dts version constraints
echo "Checking vite-plugin-dts peer dependencies..."
curl -s https://registry.npmjs.org/vite-plugin-dts/4.3.0 | jq '.peerDependencies'
# Look for any existing issues with this combination
echo "Checking for potential version conflicts..."
rg -g "package.json" "\"vite-plugin-dts\""
Length of output: 582
Script:
#!/bin/bash
# Let's check the latest version of vite-plugin-dts and its compatibility
echo "Checking latest vite-plugin-dts version and its peer dependencies..."
curl -s https://registry.npmjs.org/vite-plugin-dts/latest | jq '{version, peerDependencies}'
# Let's also check what version of Vite is being used
echo "Checking Vite version in catalog..."
cat package.json | jq '.catalog.vite'
Length of output: 458
packages/mobile/vite.config.ts (2)
11-13: Verify entry point existence and exports
The build configuration specifies './index.ts' as the entry point. Let's ensure this file exists and exports all necessary components.
✅ Verification successful
Entry point verified and exports confirmed
The entry point ./index.ts exists and properly exports all necessary components. The file contains:
- A version export
- All UI components with both their original names and prefixed variants (e.g.,
ButtonandTinyButton) - Proper imports from the components directory
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if index.ts exists and examine its exports
if [ -f "packages/mobile/index.ts" ]; then
echo "Entry point exists. Checking exports:"
rg -A 5 "export \{.*\}" "packages/mobile/index.ts"
else
echo "Warning: Entry point 'packages/mobile/index.ts' not found"
fi
Length of output: 173
Script:
#!/bin/bash
# Let's check the content of index.ts and any export statements with different patterns
echo "Checking index.ts content:"
cat packages/mobile/index.ts
echo -e "\nSearching for export statements with different patterns:"
rg "^export" packages/mobile/index.ts
echo -e "\nChecking if there might be a .js variant:"
[ -f "packages/mobile/index.js" ] && echo "index.js exists" || echo "No index.js found"
echo -e "\nListing files in packages/mobile to verify entry point location:"
ls -la packages/mobile/
Length of output: 5677
16-16: Review external dependencies pattern
The current external dependencies pattern /@better-scroll/, /@opentiny/ might be too broad. Consider being more specific to avoid accidentally excluding required dependencies.
Let's verify the impact:
✅ Verification successful
Based on the search results, I can see that @better-scroll and @opentiny dependencies are used across multiple files in the codebase. Let me analyze the specific usage patterns to determine if the external pattern is appropriate.
This will help us understand the specific import patterns and determine if the external configuration needs to be more granular.
Let me modify the search to work without file type restrictions since the Vue file type isn't recognized.
This should show us the actual import statements being used for these dependencies.
Based on the analysis of the import patterns, I can now provide a definitive response about the external dependencies configuration:
The external dependencies pattern is appropriate and should be kept as is
The current external pattern /@better-scroll/, /@opentiny/ is correctly configured because:
-
@better-scrollimports:- Used consistently in wheel and action-sheet components
- Only specific modules are imported (core and wheel)
- Used in both mobile and vue packages
-
@opentinyimports:- Used extensively throughout the codebase
- Includes various submodules (vue-common, vue-renderless, vue-theme, etc.)
- Forms the core framework of the application
The pattern is neither too broad nor restrictive because:
- It correctly excludes these dependencies from the bundle while allowing them to be resolved at runtime
- Both patterns match the actual import paths used in the codebase
- The patterns are specific to the vendor prefixes and won't accidentally exclude other dependencies
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for all @better-scroll and @opentiny imports in the codebase
echo "Checking @better-scroll imports:"
rg -l '@better-scroll'
echo "\nChecking @opentiny imports:"
rg -l '@opentiny'
Length of output: 65670
Script:
#!/bin/bash
# Check actual import patterns for these dependencies
echo "Checking @better-scroll import patterns:"
rg -A 2 '@better-scroll' --type ts --type vue
echo "\nChecking @opentiny import patterns:"
rg -A 2 '@opentiny' --type ts --type vue
Length of output: 318
Script:
#!/bin/bash
# Check actual import patterns for these dependencies
echo "Checking @better-scroll import patterns:"
rg -A 2 'from.*@better-scroll|import.*@better-scroll'
echo "\nChecking @opentiny import patterns:"
rg -A 2 'from.*@opentiny|import.*@opentiny'
Length of output: 66043
internals/cli/package.json (1)
26-26:
Address version inconsistency between Vite and its plugins
The Vite version (^4.3.8) is significantly older than the Vue plugins specified in the mobile package (@vitejs/plugin-vue@^5.2.1). This version mismatch could lead to compatibility issues.
Consider upgrading Vite to match the plugin requirements:
- "vite": "^4.3.8",
+ "vite": "^5.0.0",Let's check for any other Vite version references:
packages/utils/src/crypt/sha256.ts (2)
39-39: Verify no runtime behavior changes in SHA256 implementation
Although this is a TypeScript type-level change, please verify that the SHA256 hash outputs remain consistent after the upgrade.
Let's search for any additional changes to SHA256 implementation:
✅ Verification successful
No runtime behavior changes detected in SHA256 implementation
The only change is adding the declare keyword to the _data property in the SHA256Algo class, which is a TypeScript-only modification that gets removed during compilation. The core SHA256 algorithm implementation, including initialization vectors, round constants, and all computational logic remains completely unchanged. The property is still used in the same way within _doFinalize() method.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any other changes to SHA256 files
git diff --name-only HEAD~1 | grep -i sha256
# Search for usage patterns that might be affected
rg "new SHA256|SHA256\("
Length of output: 412
Script:
#!/bin/bash
# Let's examine the actual changes in the SHA256 implementation
git diff HEAD~1 packages/utils/src/crypt/sha256.ts
# Let's also check the full implementation to understand the context
cat packages/utils/src/crypt/sha256.ts
# Check the actual usage in the crypto index file
cat packages/utils/src/crypt/index.ts
Length of output: 4487
39-39: 🛠️ Refactor suggestion
Verify parent class initialization of _data property
While changing to declare is syntactically correct if the property is initialized in the parent class, using any type for cryptographic data reduces type safety. Consider using more specific types like WordArray or Uint8Array.
Let's verify the parent class initialization:
Consider replacing any with a more specific type:
- declare _data: any
+ declare _data: WordArray✅ Verification successful
Property declaration aligns with parent class implementation
The declare _data: any matches the parent implementation in BufferedBlockAlgorithm class where _data is initialized as a WordArray in the reset() method and is typed as any. While the type could be more specific, this maintains consistency with the parent class implementation.
Key findings:
_datais properly initialized in parent class'sreset()method:this._data = new WordArray()- The property is used throughout the codebase with
WordArrayoperations - The
anytype matches the parent class declaration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for Hasher class implementation and _data initialization
ast-grep --pattern 'class Hasher {
$$$
_data
$$$
}'
Length of output: 59
Script:
#!/bin/bash
# Let's try a different approach to find the Hasher class and _data initialization
# First, let's find the file containing Hasher class
fd "hasher" --type f
# Then let's look for _data usage in crypto-related files
rg "_data" --type ts -C 3 packages/utils/src/crypt/
Length of output: 2856
| 'vitest': '^2.1.8' | ||
| 'vite': '^6.0.0' |
There was a problem hiding this comment.
💡 Codebase verification
Version conflicts detected - Migration needed in internal packages
The verification revealed version conflicts that need attention:
- Found packages still using Vite 4.x:
internals/unplugin-tiny-vue/example/package.jsoninternals/cli/package.json
Additionally, multiple Vite and Vitest configuration files were found that may need updates:
- 15 Vite config files across various packages
- 3 Vitest config files in Vue examples
Please update the remaining Vite v4 dependencies and review all configuration files for compatibility with the new versions.
🔗 Analysis chain
Major version upgrades require careful verification
The changes include significant version jumps:
- Vite: 4.3.8 → 6.0.0 (Major upgrade)
- Vitest: 0.31.0 → 2.1.8 (Major upgrade)
These updates likely include breaking changes that need careful review.
Let's verify the package compatibility:
Please review:
Consider documenting the migration steps in the PR description to help with future upgrades.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if any package.json files still reference old versions
echo "Checking for potential version conflicts..."
rg -g "package.json" "\"vite\": \"(\^4|\~4)"
rg -g "package.json" "\"vitest\": \"(\^0|\~0)"
# Check for Vite/Vitest config files that might need updates
echo "Checking for config files that might need migration..."
fd "vite.config"
fd "vitest.config"
Length of output: 1097
| @@ -36,6 +35,12 @@ | |||
| "@opentiny/vue-locale": "workspace:~" | |||
| }, | |||
| "devDependencies": { | |||
| "vue": "^3.5.0" | |||
| "vue": "^3.5.0", | |||
There was a problem hiding this comment.
Fix incorrect Vue version specification
The specified Vue version ^3.5.0 is incorrect as Vue 3.5.0 doesn't exist yet. The latest Vue 3.x version is lower than this.
Consider updating to a valid version:
- "vue": "^3.5.0",
+ "vue": "^3.4.0",📝 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.
| "vue": "^3.5.0", | |
| "vue": "^3.4.0", |
| @@ -36,7 +36,7 @@ while (mPrime < 64) { | |||
|
|
|||
| export class SHA256Algo extends Hasher { | |||
| _hash: any | |||
| _data: any | |||
| declare _data: any | |||
There was a problem hiding this comment.
💡 Codebase verification
Missing test coverage for critical cryptographic functionality
The SHA256 implementation lacks dedicated test coverage, which is concerning for cryptographic code. The codebase shows:
- A complete SHA256 implementation in
packages/utils/src/crypt/sha256.ts - Usage in
packages/utils/src/crypt/index.tswith both WebCrypto and fallback paths - No corresponding test files found in the utils package
Key areas requiring test coverage:
- SHA256Algo class implementation
- Hash generation with different input types
- WebCrypto API fallback logic
- Edge cases and error handling
🔗 Analysis chain
Verify test coverage for SHA256 implementation
Given this is cryptographic code, ensure that the TypeScript upgrade hasn't impacted test coverage or existing test cases.
Let's check for test coverage:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for SHA256 test files
fd -e test.ts -e spec.ts sha256
# Search for SHA256 test cases
rg -l "describe.*SHA256|test.*SHA256|it.*SHA256"
Length of output: 84
Script:
#!/bin/bash
# Let's try a broader search for test files related to SHA256
fd test packages/utils/src/crypt
# Search for any SHA256-related tests with more flexible patterns
rg -i "sha256" --type ts -A 5 packages/utils/src/crypt
# Check the actual SHA256 implementation file
cat packages/utils/src/crypt/sha256.ts
Length of output: 4914
Script:
#!/bin/bash
# Let's check for any test files in the parent directories
fd test packages/utils
# Look for any imports or usage of SHA256 in test files
rg -l "SHA256|sha256" $(fd -e test.ts -e spec.ts packages/utils)
# Check if there are any test utilities or setup files
fd -e ts "test-utils|test-setup|jest.setup" packages/utils
Length of output: 812
Script:
#!/bin/bash
# Let's try with correct fd syntax
fd . packages/utils --type f --extension test.ts --extension spec.ts
# Check for any test configuration files
fd jest.config packages/utils
# Look for SHA256 usage in the codebase to understand test coverage importance
rg -p "SHA256|sha256" packages/utils/src -C 3
Length of output: 1080
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit
Release Notes
New Features
Updates
Bug Fixes
vue3dependency in package declarations.Dependency Changes