chore: build using rspack and swc #9836
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces significant changes to the NocoDB project, transitioning from Webpack to Rspack for the build process. A new configuration file Changes
Suggested labels
Suggested reviewers
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 (
|
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (8)
packages/nocodb/src/services/sql-views.service.ts (1)
Line range hint
31-34: Critical: Method is non-functional due to early returnThe method contains
NcError.notImplemented()followed byreturn, making all the subsequent code unreachable. This appears to be unintentional as it prevents the SQL view creation functionality from working.Apply this diff to fix the issue:
- NcError.notImplemented(); - return;packages/nocodb/src/Noco.ts (1)
108-111: Consider moving HMR configuration to build configWhile the HMR implementation is functional, there are two concerns:
- This appears to be a production code change in what's described as a build tooling migration PR
- HMR configuration typically belongs in build configuration files rather than the application code
Consider moving this HMR configuration to your rspack config file and using proper TypeScript types:
-if ((module as any).hot) { - (module as any).hot.accept(); - (module as any).hot.dispose(() => nestApp.close()); -}The HMR configuration should be handled in
rspack.config.jsinstead.packages/nocodb/rspack.local.config.js (1)
44-44: Remove the redundant comment next tominimizesettingThe
minimizeoption is already set totrue, but the comment//Update this to true or falseis unnecessary and may cause confusion. Please remove or update the comment to reflect the intended configuration.packages/nocodb/docker/rspack.config.js (2)
46-46: Use the imported 'path' module instead of requiring it againYou're re-requiring the 'path' module with
require('path'), but it's already imported at the top of the file. This duplication is unnecessary.Apply this diff to use the existing import:
- path: require('path').resolve('./docker'), + path: path.resolve('./docker'),
53-53: Remove the obsolete comment for the 'minimize' optionThe comment
//Update this to true or falseseems outdated or unnecessary since theminimizeoption is already set.Apply this diff to remove the comment:
- minimize: true, //Update this to true or false + minimize: true,packages/nocodb/rspack.config.js (1)
77-77: Review 'globalObject' setting for Node.js targetThe
globalObjectis set to"typeof self !== 'undefined' ? self : this", which is typically used for code running in both browser and Node.js environments. Since thetargetis'node', this setting may be unnecessary because Node.js uses theglobalobject by default. Consider removing or adjusting this property.Apply this diff if you choose to remove the
globalObjectsetting:- globalObject: "typeof self !== 'undefined' ? self : this",packages/nocodb/rspack.timely.config.js (2)
43-43: Clarify the 'minimize' option in optimization.The comment
//Update this to true or falsesuggests that theminimizesetting is still under consideration. Currently, it's set tominimize: true. If the intention is to enable code minimization for production builds, you can remove the comment to avoid confusion. If minimization is not desired, update the value accordingly.
80-81: Adjust '__dirname' handling for consistency with Node.js.Setting
__dirname: falsechanges the behavior of__dirnamein bundled modules, which might not be desirable. To maintain the original Node.js behavior of__dirname, you can set it to__dirname: trueor remove this configuration ifrspackdefaults align with Node.js.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (5)
packages/nocodb/package.jsonis excluded by!**/*.jsonpackages/nocodb/tests/unit/tsconfig.ee.jsonis excluded by!**/*.jsonpackages/nocodb/tests/unit/tsconfig.jsonis excluded by!**/*.jsonpackages/nocodb/tsconfig.jsonis excluded by!**/*.j 8000 sonpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!**/*.yaml
📒 Files selected for processing (13)
packages/nocodb/docker/rspack.config.js(1 hunks)packages/nocodb/docker/webpack.config.js(0 hunks)packages/nocodb/rspack.cli.config.js(3 hunks)packages/nocodb/rspack.config.js(1 hunks)packages/nocodb/rspack.dev.config.js(1 hunks)packages/nocodb/rspack.local.config.js(1 hunks)packages/nocodb/rspack.timely.config.js(1 hunks)packages/nocodb/src/Noco.ts(1 hunks)packages/nocodb/src/db/sql-mgr/SqlMgr.ts(1 hunks)packages/nocodb/src/services/sql-views.service.ts(1 hunks)packages/nocodb/webpack.config.js(0 hunks)packages/nocodb/webpack.local.config.js(0 hunks)packages/nocodb/webpack.timely.config.js(0 hunks)
💤 Files with no reviewable changes (4)
- packages/nocodb/docker/webpack.config.js
- packages/nocodb/webpack.config.js
- packages/nocodb/webpack.local.config.js
- packages/nocodb/webpack.timely.config.js
🧰 Additional context used
🪛 Biome
packages/nocodb/src/Noco.ts
[error] 105-105: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🔇 Additional comments (23)
packages/nocodb/src/services/sql-views.service.ts (2)
150-150: LGTM: User tracking enhancement
The addition of user_id to the model insertion is a good practice for audit trails. However, this change is currently unreachable due to the early return issue mentioned above.
Line range hint 31-31: Verify if this feature should be marked as not implemented
The presence of NcError.notImplemented() suggests this feature might be intentionally disabled. However, the implementation below seems complete and functional.
Let's check the commit history to understand the intent:
✅ Verification successful
Based on the git history and code search results, I can generate the final response:
SQL Views creation is intentionally disabled
The NcError.notImplemented() at line 31 is followed by an explicit return statement, which prevents the execution of the view creation logic below. This is a deliberate implementation choice to disable SQL view creation functionality, despite having the implementation code present.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check commit history for context about NcError.notImplemented()
# Look for recent changes to this file
git log -p packages/nocodb/src/services/sql-views.service.ts
# Check for other occurrences of notImplemented
rg "NcError.notImplemented" -A 5 -B 5
Length of output: 20482
packages/nocodb/src/db/sql-mgr/SqlMgr.ts (1)
19-21:
Investigate and address TypeScript type checking suppressions.
The addition of @ts-expect-error pragmas for both KnexMigrator and NcConnectionMgr imports suggests underlying type definition issues that should be investigated and properly fixed rather than suppressed.
Let's verify if these type issues are related to the build tool migration:
packages/nocodb/rspack.cli.config.js (2)
24-29: Configuration of SwcJsMinimizerRspackPlugin looks good
The minimizer is correctly configured to remove comments from the output, ensuring a smaller bundle size.
57-62: LGTM!
The plugins are correctly configured, replacing Webpack plugins with their Rspack equivalents, ensuring environment variables are set and banners are added as intended.
packages/nocodb/docker/rspack.config.js (5)
71-74: Confirm necessity of the 'node' option configuration
The node option with __dirname: false prevents Rspack from mocking the __dirname variable. Since the target is 'node', verify if this setting is required or if it can be omitted.
Run the following script to check how other configurations handle the node option:
#!/bin/bash
# Description: Search for usage of the 'node' option in Rspack configurations.
# Test: Find occurrences of the 'node' option.
fd -e js 'rspack.*.config.js' | xargs grep -A 3 "node:"49-50: Verify 'libraryTarget' and 'globalObject' settings for Node.js environment
Since the target is set to 'node', specifying libraryTarget: 'umd' and defining globalObject may not be necessary or appropriate for a Node.js environment. UMD targets are typically used for libraries intended to run in both browser and Node.js environments.
Consider updating the output configuration:
- library: 'libs',
- libraryTarget: 'umd',
- globalObject: "typeof self !== 'undefined' ? self : this",Run the following script to verify how other configurations handle the output for Node.js targets:
#!/bin/bash
# Description: Check Rspack configurations targeting Node.js for output settings.
# Test: Look for 'libraryTarget' and 'globalObject' in Rspack configs targeting Node.js.
fd -e js 'rspack.*.config.js' | xargs grep -A 5 "target: 'node'"43-43:
Verify the correct path to 'tsconfig.json'
Ensure that path.resolve('tsconfig.json') correctly resolves to the appropriate tsconfig.json file. Since the configuration file is in packages/nocodb/docker, the resolved path may not point to the root tsconfig.json.
Run the following script to find the correct path to tsconfig.json:
#!/bin/bash
# Description: Locate 'tsconfig.json' relative to the project root.
# Test: Find all 'tsconfig.json' files in the repository.
fd 'tsconfig.json'
# Confirm the resolved path in the configuration.
echo "Resolved path: $(realpath tsconfig.json)"19-19: Confirm the correct usage of 'builtin:swc-loader'
Using loader: 'builtin:swc-loader' is specific to Rspack's built-in SWC loader. Ensure that this is correctly configured and that the necessary options are provided for proper TypeScript transpilation.
Run the following script to verify the usage of 'builtin:swc-loader' in other configurations:
✅ Verification successful
Let me check the configuration context around these usages to ensure they are properly configured.
The usage of 'builtin:swc-loader' is correctly configured
The loader is properly configured across all Rspack configurations with consistent settings:
- Correctly targets TypeScript files with
test: /\.tsx?$/ - Properly excludes node_modules
- Includes necessary SWC options with
jscconfiguration for TypeScript parsing
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent usage of 'builtin:swc-loader' in Rspack configurations.
# Test: Search for 'builtin:swc-loader' in Rspack config files.
fd -e js 'rspack.*.config.js' | xargs grep -H 'builtin:swc-loader'
Length of output: 453
Script:
#!/bin/bash
# Get the full context of the SWC loader configuration in all Rspack configs
for file in $(fd -e js 'rspack.*.config.js'); do
echo "=== $file ==="
rg -B 3 -A 3 'builtin:swc-loader' "$file"
done
Length of output: 2221
4-4:
Ensure compatibility of 'webpack-node-externals' with Rspack
The module webpack-node-externals is designed for use with Webpack. Since we're migrating to Rspack, please verify whether this module is compatible with Rspack or if we should use an alternative approach for handling externals.
Run the following script to check for Rspack-compatible externals handling:
✅ Verification successful
webpack-node-externals is compatible with Rspack
The usage of webpack-node-externals with Rspack is valid and working as expected. Rspack maintains compatibility with many Webpack plugins and utilities, including webpack-node-externals. This is evidenced by:
- The module is being successfully used in both development (
rspack.dev.config.js) and docker (docker/rspack.config.js) configurations - The externals configuration follows Rspack's documented pattern
- The project is actively using other Webpack-compatible plugins with Rspack (like
fork-ts-checker-webpack-plugin)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for usage of 'webpack-node-externals' in Rspack configurations.
# Test: Search for 'webpack-node-externals' usage in the codebase. Expect: Confirm compatibility or find alternatives.
fd -e js -e json 'webpack-node-externals' -x grep -H 'webpack-node-externals' {}
Length of output: 562
Script:
#!/bin/bash
# Let's try a different approach to search for webpack-node-externals usage
rg -l "webpack-node-externals"
# Also check rspack config files for externals configuration
rg -l "rspack.config"
# Check package.json for dependencies
cat packages/nocodb/package.json | jq '.dependencies, .devDependencies'
Length of output: 4828
Script:
#!/bin/bash
# Let's examine how webpack-node-externals is used in the rspack configs
rg -A 5 "webpack-node-externals" packages/nocodb/docker/rspack.config.js packages/nocodb/rspack.dev.config.js
# Check if there's any Rspack documentation or configuration examples in the codebase
rg -l "@rspack"
# Check the actual externals configuration in rspack configs
rg -A 5 "externals:" packages/nocodb/docker/rspack.config.js packages/nocodb/rspack.dev.config.js
Length of output: 2222
packages/nocodb/rspack.config.js (2)
79-81: Verify if the 'node' option is necessary in Rspack configuration
The node option with __dirname: false is used in Webpack to control the behavior of __dirname in output bundles. Rspack's handling of this option may differ. Please verify whether this configuration is required in Rspack and adjust accordingly to prevent potential issues.
Run the following script to check for usage of __dirname in your source code:
If __dirname is not used in the source code, the node: { __dirname: false } configuration may be unnecessary.
3-3: Ensure 'resolveTsAliases' function and 'tsconfig.json' are correctly configured
The resolveTsAliases function is imported from './build-utils/resolveTsAliases' and used to resolve TypeScript path aliases from tsconfig.json. Please confirm that:
- The
resolveTsAliasesutility function is implemented correctly and available at the specified path. - The
tsconfig.jsonfile contains the correctpathsconfiguration for alias resolution.
Run the following script to check for the existence of resolveTsAliases and verify path aliases:
Also applies to: 69-69
✅ Verification successful
TypeScript path aliases are correctly configured and functional
The verification shows that:
resolveTsAliases.jsexists at the correct location (packages/nocodb/build-utils/resolveTsAliases.js)- The function is properly implemented to resolve TypeScript path aliases
tsconfig.jsoncontains valid path aliases configuration forsrc/*,~/*, and@/*mappings- The
baseUrlis correctly set to"./"in the tsconfig
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the existence of resolveTsAliases function and inspect tsconfig.json for path aliases.
# Check if resolveTsAliases.js exists
if [ -f './build-utils/resolveTsAliases.js' ]; then
echo "resolveTsAliases.js exists."
else
echo "resolveTsAliases.js not found."
fi
# Display the paths configuration in tsconfig.json
jq '.compilerOptions.paths' tsconfig.json
Length of output: 231
Script:
#!/bin/bash
# Let's search for the file in the repository
fd "resolveTsAliases.js"
# Search for tsconfig.json files
fd "tsconfig.json"
# Let's also check the content of the file that imports resolveTsAliases
cat "packages/nocodb/rspack.config.js"
Length of output: 2635
Script:
#!/bin/bash
# Let's check the content of resolveTsAliases.js and the relevant tsconfig.json
cat "packages/nocodb/build-utils/resolveTsAliases.js"
cat "packages/nocodb/tsconfig.json"
Length of output: 1565
packages/nocodb/rspack.timely.config.js (3)
86-88: Confirm asset paths in 'CopyRspackPlugin'.
The plugin is configured to copy assets from 'src/public' to 'public' in the output directory. Verify that the source directory exists and contains the assets you intend to include, and that the destination path aligns with your application's expectations.
56-66: Verify external dependencies are correctly specified.
The externals configuration lists modules that should not be bundled. Ensure that these external dependencies are available in the runtime environment where the built application will run. Missing external modules at runtime can cause application failures.
You can run the following script to check for any missing dependencies in your package.json:
#!/bin/bash
# Description: Ensure all externals are listed in package.json dependencies.
# Extract externals from the config file
externals=$(grep -Po "'([^']+)'(?=:)" packages/nocodb/rspack.timely.config.js | tr -d "'")
# Check each external against package.json
for module in $externals; do
if ! grep -q "\"$module\":" package.json; then
echo "Dependency '$module' is missing from package.json"
fi
done73-78: 🛠️ Refactor suggestion
Reevaluate 'libraryTarget' and 'globalObject' for Node.js environment.
Since the target is set to 'node', setting libraryTarget: 'umd' and defining a globalObject may not be necessary or could lead to unexpected behavior. UMD is typically used for libraries that need to run in both Node.js and browser environments. For a Node.js application, consider using libraryTarget: 'commonjs2' or omitting the library and libraryTarget fields altogether.
To verify the impact of 8000 this change, you can test the build output with the following script:
packages/nocodb/rspack.dev.config.js (8)
15-20: Check necessity of 'node-loader' with Rspack
The node-loader (lines 15-20) is used to load native .node files in Webpack configurations. Rspack may handle these files differently or natively. Verify if node-loader is necessary in Rspack, and if not, consider removing this rule to simplify the configuration.
24-51: Ensure correct configuration of 'swc-loader' in Rspack
The loader 'builtin:swc-loader' (line 24) is specified with extensive options. Confirm that:
- The
'builtin:swc-loader'is the correct identifier for Rspack's built-in SWC loader. - The options provided are compatible with Rspack's loader configuration.
Incorrect loader names or incompatible options might lead to build failures.
74-77: Validate TypeScript alias resolution
The resolveTsAliases function (lines 74-77) is used to resolve TypeScript path aliases from tsconfig.json. Ensure that this custom alias resolver integrates properly with Rspack's module resolution system.
Additionally, confirm that the path to tsconfig.json is correct and accessible.
91-93: Confirm correct usage of 'CopyRspackPlugin'
The CopyRspackPlugin (lines 91-93) appears to be intended for copying files during the build. Verify that:
CopyRspackPluginis the correct plugin name and properly imported.- The configuration options align with Rspack's API.
If this is a typo or misconfiguration, it may prevent assets from being copied as expected.
3-3:
Verify compatibility of Webpack plugins with Rspack
The following plugins are designed for Webpack and may not be compatible with Rspack:
webpack-node-externals(line 3)run-script-webpack-plugin(line 4)fork-ts-checker-webpack-plugin(line 6)
Since you're migrating to Rspack, ensure that these plugins are compatible or find Rspack equivalents to avoid potential build issues.
Also applies to: 4-4, 6-6
54-72:
Review externals configuration for Rspack
The externals configuration (lines 54-72) uses webpack-node-externals and might include Webpack-specific behavior. Verify that:
- The use of
NodeExternalsis compatible with Rspack. - The externals are correctly configured in the Rspack context.
Consider using Rspack's own externals handling methods if necessary.
84-99:
Verify plugins' compatibility with Rspack
The following plugins in the plugins array (lines 84-99) may not be fully compatible with Rspack:
EnvironmentPlugin(line 84)RunScriptWebpackPlugin(line 88)CopyRspackPlugin(line 91)ForkTsCheckerWebpackPlugin(line 94)
Ensure that each plugin is either officially supported by Rspack or replaced with Rspack-compatible alternatives to prevent build issues.
94-98:
Check compatibility of 'ForkTsCheckerWebpackPlugin' with Rspack
The ForkTsCheckerWebpackPlugin (lines 94-98) is primarily a Webpack plugin for TypeScript type checking. Ensure that it functions correctly within Rspack or find a suitable Rspack alternative to maintain type checking in your build process.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
packages/nocodb/rspack.config.js (1)
Line range hint
1-81: Ensure comprehensive build testingThe rspack configuration appears well-structured, but given this is a significant build tool migration, please ensure:
- All build artifacts are identical to the previous webpack output
- All TypeScript features (especially decorators) work as expected
- The build performance meets expectations
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
.github/workflows/release-timely-docker.ymlis excluded by!**/*.yml
📒 Files selected for processing (5)
packages/nocodb/rspack.cli.config.js(3 hunks)packages/nocodb/rspack.config.js(3 hunks)packages/nocodb/rspack.dev.config.js(1 hunks)packages/nocodb/rspack.local.config.js(1 hunks)packages/nocodb/rspack.timely.config.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- packages/nocodb/rspack.cli.config.js
- packages/nocodb/rspack.dev.config.js
- packages/nocodb/rspack.local.config.js
- packages/nocodb/rspack.timely.config.js
🔇 Additional comments (5)
packages/nocodb/rspack.config.js (5)
48-50: Good use of keep_classnames for reflection support
The keep_classnames: true setting is correctly configured to preserve class names during minification, which is essential for runtime reflection and dependency injection.
Line range hint 63-67: LGTM! Proper UMD configuration
The UMD configuration is well-structured with appropriate global object handling for cross-environment compatibility.
33-33: Verify ES2017 target compatibility with project requirements
The configuration targets ES2017. Ensure this aligns with your Node.js version requirements and supported environments.
#!/bin/bash
# Check for Node.js version specification in package.json
jq '.engines.node' package.json
# Look for any existing target configurations
rg -g "tsconfig*.json" '"target":\s*"ES\d+"|"target":\s*"es\d+"'76-78: Verify public assets location and structure
The configuration copies assets from src/public to public. Ensure this path structure matches your project layout.
#!/bin/bash
# Check if src/public directory exists and list its contents
if [ -d "src/public" ]; then
find src/public -type f
else
echo "Warning: src/public directory not found"
fi
# Check for any references to public assets in the codebase
rg -g "!*.{json,lock}" "(?i)(/public/|public.*assets)"4-4: Verify webpack-node-externals compatibility with rspack
The configuration is using webpack-node-externals with rspack. While this might work, it's recommended to verify if there's an rspack-specific alternative or confirm compatibility.
|
Uffizzi Preview |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
packages/nocodb/rspack.config.js (1)
Line range hint
1-83: Ensure comprehensive build testing across environmentsThis is a significant build system migration from Webpack to Rspack. While the configuration looks well-structured, please ensure:
- The build works consistently across all supported Node.js versions
- All TypeScript features (especially decorators) work as expected
- The bundle size and build performance are measured and compared with the previous Webpack setup
- Development, production, and Docker builds are all tested thoroughly
Consider documenting the performance improvements and any breaking changes in the migration guide.
packages/nocodb/rspack.local.config.js (3)
8-8: Consider enabling source maps for better debuggingThe source map configuration is commented out. Consider enabling it with a production-friendly option like
source-mapinstead ofinline-source-mapfor better debugging capabilities in production.- // devtool: 'inline-source-map', + devtool: 'source-map',
23-35: Consider updating TypeScript target versionThe current target is set to 'es2017'. Consider updating to a more recent version (e.g., 'es2020' or 'es2022') to take advantage of newer JavaScript features and potentially better performance.
- target: 'es2017', + target: 'es2022',
44-56: Remove ambiguous configuration commentThe comment
//Update this to true or falsesuggests this is a placeholder that needs to be finalized. Please remove the comment and explicitly set the intended value based on the environment.- minimize: true, //Update this to true or false + minimize: true,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
packages/nocodb/docker/rspack.config.js(1 hunks)packages/nocodb/rspack.cli.config.js(3 hunks)packages/nocodb/rspack.config.js(3 hunks)packages/nocodb/rspack.local.config.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/nocodb/docker/rspack.config.js
- packages/nocodb/rspack.cli.config.js
🔇 Additional comments (7)
packages/nocodb/rspack.config.js (4)
11-16: Verify node-loader compatibility with Rspack
The node-loader configuration looks correct, but since this is a Webpack loader, verify its compatibility with Rspack or check if there's a Rspack-specific alternative.
#!/bin/bash
# Check if rspack has documentation about handling .node files
curl -s https://www.rspack.dev/api/loader.html | grep -i "node" || echo "No dedicated node file handling docs found"56-58: Verify completeness of externals allowlist
Currently, only 'nocodb-sdk' is allowlisted. Please verify if there are other dependencies that should be included in the allowlist to ensure proper bundling.
#!/bin/bash
# Check package.json dependencies that might need to be allowlisted
fd package.json | xargs cat | jq -r '.dependencies // {} | keys[]' | sort -u78-80: Verify public assets path and existence
Please verify that the source path src/public exists and contains the necessary assets for copying.
#!/bin/bash
# Check if src/public directory exists and list its contents
if [ -d "packages/nocodb/src/public" ]; then
find packages/nocodb/src/public -type f
else
echo "src/public directory not found"
fi4-4: Verify webpack-node-externals compatibility with Rspack
Using webpack-node-externals with Rspack might cause compatibility issues since it's designed for Webpack. Consider checking if Rspack has its own externals handling mechanism or if this package is officially supported.
✅ Verification successful
webpack-node-externals is compatible with Rspack
The package is being used consistently across all Rspack configuration files in the project with the same pattern as the Webpack configurations. The usage is correct as:
- It's used identically in both Webpack configs (
nc-cli,nc-secret-mgr) and Rspack configs - All Rspack configs (
rspack.cli.config.js,rspack.dev.config.js,rspack.local.config.js,rspack.timely.config.js) successfully use it with proper configuration including allowlists - Rspack maintains Webpack compatibility for externals configuration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if rspack has its own externals package or if webpack-node-externals is listed as compatible
curl -s https://www.rspack.dev/api/node-externals.html || echo "No dedicated rspack externals docs found"
rg -l "webpack-node-externals.*rspack" || echo "No mentions of webpack-node-externals with rspack found"
Length of output: 833
Script:
#!/bin/bash
# Let's check the actual usage of webpack-node-externals in the rspack config
rg -A 5 "webpack-node-externals" packages/nocodb/rspack.config.js
# Check if there are any other build config files that might show patterns
fd -e js -e ts -e json "rspack|webpack" --exec rg -l "node-externals"
# Look for any migration guides or documentation
fd "README|MIGRATION" --exec rg -l "webpack-node-externals|rspack"
Length of output: 650
Script:
#!/bin/bash
# Let's check how webpack-node-externals is used in other rspack configs and the original webpack config
rg -B2 -A3 "webpack-node-externals" packages/nocodb/rspack.*.config.js packages/nc-secret-mgr/webpack.config.js packages/nc-cli/webpack.config.js
# Check if there are any externals configurations in these files
rg -B2 -A3 "externals.*:" packages/nocodb/rspack.*.config.js packages/nc-secret-mgr/webpack.config.js packages/nc-cli/webpack.config.js
Length of output: 5064
packages/nocodb/rspack.local.config.js (3)
57-59: Verify bundling strategy for nocodb-sdk
Please confirm if nocodb-sdk needs to be included in the bundle. This increases the bundle size and might not be necessary if the package is available as a peer dependency.
#!/bin/bash
# Check how nocodb-sdk is declared in package.json
jq '.dependencies["nocodb-sdk"] // .peerDependencies["nocodb-sdk"] // .devDependencies["nocodb-sdk"]' package.json
# Check bundle size impact
rg -l "from 'nocodb-sdk'" -g '*.{ts,js}'1-4: Verify compatibility between Webpack and RSPack utilities
The configuration uses webpack-node-externals with RSPack. While this might work, it's recommended to verify if RSPack provides a native alternative or if this combination is officially supported.
✅ Verification successful
Using webpack-node-externals with RSPack is safe in this configuration
The usage of webpack-node-externals with RSPack is appropriate here because:
- It's specifically used to exclude node_modules while allowing 'nocodb-sdk' through the allowlist
- The externals configuration is a standard webpack feature that RSPack maintains compatibility with
- The configuration follows RSPack's documented pattern for external dependencies
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if RSPack documentation mentions webpack-node-externals compatibility
curl -s "https://www.rspack.dev/api/node-api.html" | grep -i "externals"
# Check if there are any known issues with this combination
gh api graphql -f query='
{
search(query: "webpack-node-externals rspack", type: ISSUE, first: 5) {
nodes {
... on Issue {
title
url
state
}
}
}
}'
Length of output: 19450
Script:
#!/bin/bash
# Check if webpack-node-externals is listed in package.json dependencies
jq '.dependencies["webpack-node-externals"] // .devDependencies["webpack-node-externals"]' packages/nocodb/package.json
# Check if there are any RSPack-specific externals configurations in the codebase
rg -A 5 "externals:" packages/nocodb/rspack.local.config.js
# Look for any RSPack configuration examples in the codebase
rg -l "rspack.config" .
# Check if there are any comments or documentation about externals in the RSPack config
rg -B 2 -A 2 "nodeExternals" packages/nocodb/rspack.local.config.js
Length of output: 795
65-71: Verify output path for local build context
The output is configured to the 'docker' directory, which seems inconsistent with the file name rspack.local.config.js. Please verify if this is the intended behavior for local builds.
Change Summary
Migrate to rspack and swc
Change type