fix(rspack): rspack builder usage without installing webpack #29823
Conversation
|
|
WalkthroughThe changes in this pull request involve the addition of the Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
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 (
|
|
Then how should I declare the type for the |
e22d760 to
3e68b8c
Compare
|
yes - the types for |
Done, not sure about the typecheck part tho. If there is any way to remove the |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
packages/rspack/package.json (1)
Line range hint
1-94: Consider cleaning up webpack-specific dependencies.Given that this is the rspack builder package, consider reviewing and potentially removing or replacing the following webpack-specific dependencies with rspack equivalents:
- webpack-bundle-analyzer
- webpack-dev-middleware
- webpack-hot-middleware
- webpack-virtual-modules
This would further reduce the webpack footprint in the rspack builder.
packages/webpack/package.json (1)
75-75: Document the rationale for the major version upgrade.Consider adding a comment in the PR description or commit message explaining why this major version upgrade was necessary, particularly how it relates to fixing the rspack builder's webpack dependency issue.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (6)
packages/rspack/builder.mjs(1 hunks)packages/rspack/package.json(1 hunks)packages/webpack/builder.d.ts(1 hunks)packages/webpack/builder.mjs(1 hunks)packages/webpack/package.json(1 hunks)packages/webpack/src/presets/base.ts(3 hunks)
🔇 Additional comments (10)
packages/webpack/builder.mjs (1)
4-4: LGTM! The export addition aligns with the PR objectives.
This change is part of the strategy to make builders work independently, allowing rspack to function without webpack by using appropriate plugins from webpackbar.
Let's verify the webpackbar version compatibility:
✅ Verification successful
The webpackbar v7 upgrade appears compatible with existing usage
The verification shows:
- Both webpack and rspack builders use webpackbar v7.0.0 consistently
- The usage in
base.tsmatches webpackbar's API, including progress reporting and hooks - The package supports both webpack and rspack via peer dependencies
- All hook definitions in schema are properly aligned with the webpackbar events
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for breaking changes in webpackbar v7 that might affect existing usage
# Test: Look for webpackbar usage patterns that might need updates
rg -g '!node_modules' -g '!*.lock' -g '!package*.json' 'webpackbar|WebpackBar' -A 5
# Test: Check package.json files for webpackbar dependency
rg -g 'package.json' '"webpackbar":'
Length of output: 7797
packages/rspack/builder.mjs (2)
3-4: LGTM! The change aligns with the PR objectives.
The addition of WebpackBarPlugin from webpackbar/rspack is a good solution that helps decouple the rspack builder from webpack dependencies.
Let's verify the webpackbar dependency configuration:
✅ Verification successful
Verified: WebpackBarPlugin import change is correct and properly configured
The verification confirms:
- Webpackbar dependency is correctly set to version ^7.0.0 in package.json
- The rspack-specific import path 'webpackbar/rspack' is used in rspack builder
- The webpack builder maintains its separate import from 'webpackbar'
This change successfully contributes to decoupling rspack from webpack dependencies while maintaining parallel implementations for both builders.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify webpackbar dependency and its version in package.json
# Expected: Should find webpackbar dependency with version ^7.0.0
# Check package.json for webpackbar dependency
echo "Checking webpackbar dependency configuration:"
jq '.dependencies.webpackbar' packages/rspack/package.json
Length of output: 168
Script:
#!/bin/bash
# Let's verify if webpackbar/rspack module exists and is properly exported
fd webpackbar node_modules -t f | grep -i rspack
# Also check if there are any other files importing WebpackBarPlugin
rg "WebpackBarPlugin.*from.*webpackbar" -g '!node_modules' -g '!*.md'
Length of output: 300
1-7: Consider documenting the major version upgrade impact.
The upgrade of webpackbar from v6 to v7 is a major version change. While the current implementation looks correct, it would be helpful to document any breaking changes or new features that influenced this decision.
Let's check for any other webpackbar usages that might need updates:
packages/webpack/builder.d.ts (1)
6-6: LGTM! Verify type availability in both contexts.
The type declaration for WebpackBarPlugin follows the correct pattern, consistent with other exports like MiniCssExtractPlugin. The direct type import from webpackbar resolves the previous any type issue.
Let's verify the type availability in both webpack and rspack contexts:
✅ Verification successful
Type declaration is correct and compatible with both webpack and rspack contexts
The verification shows that:
- Both packages have webpackbar v7.0.0 as a dependency
- The webpack builder imports from 'webpackbar'
- The rspack builder imports from 'webpackbar/rspack'
- The type declaration in
builder.d.tscorrectly references the default export from webpackbar, which is compatible with both contexts since the rspack-specific import is handled at the implementation level
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if webpackbar types are accessible in both webpack and rspack contexts
# Test 1: Check for webpackbar dependency in both builders
echo "Checking webpackbar dependency..."
jq '.dependencies.webpackbar' packages/webpack/package.json
jq '.dependencies.webpackbar' packages/rspack/package.json
# Test 2: Look for any other imports of webpackbar types
rg -t ts "from ['|\"]webpackbar"
Length of output: 250
Script:
#!/bin/bash
# Let's verify the actual usage of webpackbar in both webpack and rspack builders
# Check for webpackbar imports and usage in both packages
echo "=== Checking webpackbar usage in webpack builder ==="
rg -l "webpackbar" packages/webpack/
echo -e "\n=== Checking webpackbar usage in rspack builder ==="
rg -l "webpackbar" packages/rspack/
# Check the actual implementation to see how WebpackBarPlugin is used
echo -e "\n=== Checking WebpackBarPlugin implementation details ==="
rg -A 5 "WebpackBarPlugin" packages/webpack/
rg -A 5 "WebpackBarPlugin" packages/rspack/
Length of output: 2351
packages/rspack/package.json (1)
75-75: Verify webpackbar v7.0.0 compatibility and webpack dependency.
The upgrade to webpackbar v7.0.0 appears to be related to resolving the webpack dependency issue. Let's verify this change.
✅ Verification successful
Webpackbar v7.0.0 upgrade resolves webpack dependency issue
The upgrade to webpackbar v7.0.0 is verified to resolve the webpack dependency issue as:
- Webpackbar v7.0.0 no longer has webpack as a direct dependency, as shown in its package.json dependencies
- The version is consistently used across both webpack and rspack packages, avoiding any conflicts
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description:
# 1. Check if webpackbar v7.0.0 has webpack as a direct dependency
# 2. Verify compatibility with other dependencies
# Check webpackbar's package.json for dependencies
echo "Checking webpackbar v7.0.0 dependencies..."
curl -s https://registry.npmjs.org/webpackbar/7.0.0 | jq '.dependencies'
# Check for potential version conflicts with other dependencies
echo "Checking for dependency conflicts..."
rg '"webpackbar":' -g 'package.json'
Length of output: 497
packages/webpack/package.json (1)
75-75: Verify breaking changes in webpackbar v7.0.0.
The major version bump from ^6.0.1 to ^7.0.0 suggests breaking changes. While this update might help resolve the webpack dependency issue in the rspack builder, we should ensure compatibility.
Let's verify the changes:
✅ Verification successful
Breaking changes verification successful - update is safe
The version bump from 6.x to 7.x is safe because:
- Both webpack and rspack packages use the same version (^7.0.0)
- Rspack builder imports from
webpackbar/rspackspecifically - WebpackBarPlugin usage is properly isolated between builders:
- Webpack builder: Uses default import from
webpackbar - Rspack builder: Uses rspack-specific import from
webpackbar/rspack
- Webpack builder: Uses default import from
- The plugin configuration in webpack's base.ts remains compatible
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential breaking changes and usage patterns
# Test 1: Check if webpackbar is imported in both webpack and rspack builders
echo "Checking webpackbar usage patterns:"
rg -l 'webpackbar'
# Test 2: Look for WebpackBar or WebpackBarPlugin usage
echo "Checking specific plugin usage:"
rg -A 2 'WebpackBar(Plugin)?'
# Test 3: Check package.json files for webpackbar dependency
echo "Checking webpackbar versions across packages:"
fd -g 'package.json' -x grep -l 'webpackbar'
Length of output: 4154
Script:
#!/bin/bash
# Let's check the specific versions and usage differences between webpack and rspack packages
# Check the exact versions in both package.json files
echo "Checking webpackbar versions:"
echo "webpack/package.json:"
cat packages/webpack/package.json | grep "webpackbar"
echo "rspack/package.json:"
cat packages/rspack/package.json | grep "webpackbar"
# Check how WebpackBarPlugin is used in both builders
echo -e "\nChecking WebpackBarPlugin usage in webpack builder:"
cat packages/webpack/src/presets/base.ts | grep -A 10 "WebpackBarPlugin"
echo -e "\nChecking WebpackBarPlugin usage in rspack builder:"
cat packages/rspack/builder.mjs | grep -A 5 "WebpackBarPlugin"
# Check if there are any webpack-specific imports or usage
echo -e "\nChecking for webpack-specific imports:"
rg "from 'webpack'" -A 2
Length of output: 4878
packages/webpack/src/presets/base.ts (4)
17-17: LGTM! Import change improves modularity.
The change to import from '#builder' instead of directly from 'webpackbar' aligns with the goal of making the rspack builder work independently of webpack.
Let's verify the usage of these imports throughout the codebase:
#!/bin/bash
# Description: Verify that we're consistently using the new imports from #builder
# and not mixing with direct webpack imports
# Check for any remaining direct webpackbar imports
echo "Checking for direct webpackbar imports..."
rg "from 'webpackbar'" --type ts
# Check for consistent usage of WebpackBarPlugin
echo "Checking WebpackBarPlugin usage..."
rg "new WebpackBarPlugin" --type tsLine range hint 90-103: Type declaration needs improvement.
The @ts-expect-error comment indicates unresolved type issues with the stats option. This should be properly typed to ensure type safety.
Let's check if this is a common pattern or if we can find the correct type:
#!/bin/bash
# Description: Check for similar type issues in other files
# and verify if there's a proper type definition we can use
# Look for similar @ts-expect-error comments
echo "Checking for similar type issues..."
rg "@ts-expect-error.*WebpackBar" --type ts
# Check if the type is defined in the builder types
echo "Checking builder type definitions..."
fd -e d.ts -x cat {} \; | rg -A 5 "WebpackBarPlugin"103-107: Verify error handling behavior change.
The error checking has changed from state.hasErrors to stats.hasErrors(). While this appears to be the correct API change, we should ensure it handles all error cases consistently.
Let's verify the error handling behavior:
#!/bin/bash
# Description: Check for consistent error handling patterns
# and verify if we're missing any error cases
# Look for other error handling patterns
echo "Checking error handling patterns..."
rg "hasErrors" --type ts -A 2
# Check for other stats usage
echo "Checking stats usage patterns..."
rg "stats\.compilation" --type ts -A 2113-115: Ensure hook parameter types are updated.
The progress callback now uses webpackbar.statesArray. Make sure the hook types in your builder's type definitions match this new structure.
Let's verify the hook type definitions:
🔗 Linked issue
Resolves #29811.
📚 Description
Checking what's the type of builder using and importing it to avoid modules not found problem.
Summary by CodeRabbit
New Features
WebpackBarPluginfor improved build progress reporting and error handling.Dependency Updates
webpackbardependency from version^6.0.1to^7.0.0in both@nuxt/rspack-builderand@nuxt/webpack-builderpackages.Bug Fixes