perf(rspack,webpack): drop lodash-es dependency
#30409
Conversation
|
|
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/klona@2.0.6, npm/knip@5.41.1, npm/knitwork@1.2.0, npm/markdownlint-cli@0.43.0 |
|
Warning Rate limit exceeded@danielroe has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 18 minutes and 26 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
Pull Request Changes AnalysisWalkthroughThe pull request introduces modifications across multiple files in the webpack and kit packages. In 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: 1
🧹 Nitpick comments (1)
packages/kit/src/template.ts (1)
47-49: Grammar correction in documentation
Consider adjusting the sentence structure for flow. For example, changing “Renders given types during build to disk … and register them as types.” to “Renders the specified types during the build to the project’sbuildDirand registers them as types.” would be more grammatically consistent./** - * Renders given types during build to disk in the project `buildDir` - * and register them as types. + * Renders the specified types during the build to the project `buildDir` + * and registers them as types. */
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
packages/rspack/package.jsonis excluded by!**/package.jsonpackages/webpack/package.jsonis excluded by!**/package.jsonpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!pnpm-lock.yaml
📒 Files selected for processing (3)
docs/1.getting-started/12.upgrade.md(1 hunks)packages/kit/src/template.ts(2 hunks)packages/webpack/src/utils/config.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/webpack/src/utils/config.ts
🔇 Additional comments (1)
packages/kit/src/template.ts (1)
17-17: Minor clarity update regarding rendering documentation
The revised comment correctly reflects where the rendered templates are placed, although it might help to reference the distinction between purely virtual output and the optional write-to-disk behaviour for even greater clarity.
docs/1.getting-started/12.upgrade.md
Outdated
| * Use `es-toolkit/compat` (a drop-in replacement for lodash template), as a dependency of _your_ project rather than Nuxt: | ||
|
|
||
| ```diff | ||
| + import { readFileSync } from 'node:fs' | ||
| + import { template } from 'lodash-es' | ||
| + import { template } from 'es-toolkit/compat' |
There was a problem hiding this comment.
💡 Codebase verification
Update documentation and code references to reflect template engine change
The verification reveals several items that need attention:
- The documentation in
packages/schema/src/config/build.tsstill referenceslodash/templateand needs to be updated to reflect the newes-toolkit/compatusage. - Neither
es-toolkitnorlodashappears in the package.json dependencies, which aligns with the documentation stating thates-toolkitshould be a dependency of the user's project rather than Nuxt. - There are template-related implementations in the codebase, particularly in the UI templates and core functionality, but they don't appear to be using lodash's template engine.
Action items:
- Update the documentation in
packages/schema/src/config/build.tsto referencees-toolkit/compatinstead oflodash/template - Consider adding a note in the upgrade guide about removing any existing
lodashdependencies if they were only used for templating
🔗 Analysis chain
Verify es-toolkit/compat import and documentation
Ensure that the project’s dependencies include es-toolkit and that developers are aware they may need to install it separately. The updated instructions appear correct, but please confirm that you have also updated any references to lodash/template in your downstream files and scripts.
Let me gather more information to verify the usage and implementation details.
Let me check one more aspect to ensure we have a complete picture.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# 1. Verify if 'es-toolkit' is declared within package.json
rg '"es-toolkit"' package.json
# 2. Check if leftover references to lodash/template still exist in the codebase
rg 'lodash.template'
Length of output: 856
Script:
#!/bin/bash
# 1. Check for any direct imports of lodash/template in the codebase
rg "from ['\"](lodash|lodash/template)['\"]"
# 2. Search for template-related imports and usage
rg "import.*template" -g "!*.md"
# 3. Look for .ejs file references
fd ".ejs$"
# 4. Check package.json for any lodash dependencies
rg '"lodash"' package.json
Length of output: 2081
Script:
#!/bin/bash
# Check for any template-related functionality in source files
ast-grep --pattern 'template($$$)'
# Look for any remaining lodash template usage
rg -i "lodash.*template" -g "!*.md" -g "!package.json"
Length of output: 662
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
packages/rspack/package.jsonis excluded by!**/package.jsonpackages/webpack/package.jsonis excluded by!**/package.jsonpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!pnpm-lock.yaml
📒 Files selected for processing (3)
packages/webpack/src/presets/base.ts(3 hunks)packages/webpack/src/utils/config.ts(1 hunks)packages/webpack/src/webpack.ts(2 hunks)
🧰 Additional context used
🪛 GitHub Check: build
packages/webpack/src/utils/config.ts
[failure] 66-66:
Parameter 'preset' implicitly has an 'any' type.
🔇 Additional comments (4)
packages/webpack/src/webpack.ts (2)
18-18: Ensure usage consistency for applyPresets.
You have imported applyPresets but only appear to call it once. Verify whether any additional usage or cleaning up is required for consistency.
31-31: Configuration retrieval is now direct.
Returning ctx.config directly simplifies the logic. Ensure that all relevant preset applications happen prior to this step for consistency.
packages/webpack/src/presets/base.ts (2)
12-12: Dependency choice acknowledged.
Using defu is a neat solution to merge objects flexibly without losing nested properties.
Line range hint 31-49: defu usage merges runtime and default config.
This approach supports deeper merges. Confirm the final structure includes all key fields, especially from ctx.config and ctx.userConfig.
packages/webpack/src/utils/config.ts
Outdated
| export async function getWebpackConfig (ctx: WebpackConfigContext, preset): Promise<Configuration> { | ||
| // Clone to avoid leaking config between Client and Server | ||
| // TODO: rewrite webpack implementation to avoid necessity for this | ||
| return cloneDeep(ctx.config) | ||
| await applyPresets(ctx, preset) | ||
| return ctx.config |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Parameter needs explicit type.
The preset parameter’s type is implicitly any. Define an interface or use a generic type to improve type safety.
Apply this patch to avoid implicit any type:
-export async function getWebpackConfig (ctx: WebpackConfigContext, preset): Promise<Configuration> {
+export async function getWebpackConfig (ctx: WebpackConfigContext, preset: WebpackConfigPresetItem | WebpackConfigPresetItem[]): Promise<Configuration> {
await applyPresets(ctx, preset)
return ctx.config
}📝 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.
| export async function getWebpackConfig (ctx: WebpackConfigContext, preset): Promise<Configuration> { | |
| // Clone to avoid leaking config between Client and Server | |
| // TODO: rewrite webpack implementation to avoid necessity for this | |
| return cloneDeep(ctx.config) | |
| await applyPresets(ctx, preset) | |
| return ctx.config | |
| export async function getWebpackConfig (ctx: WebpackConfigContext, preset: WebpackConfigPresetItem | WebpackConfigPresetItem[]): Promise<Configuration> { | |
| // Clone to avoid leaking config between Client and Server | |
| // TODO: rewrite webpack implementation to avoid necessity for this | |
| await applyPresets(ctx, preset) | |
| return ctx.config |
🧰 Tools
🪛 GitHub Check: build
[failure] 66-66:
Parameter 'preset' implicitly has an 'any' type.
es-toolkit dependencylodash-es dependency
🔗 Linked issue
📚 Description
This is a performance improvement for webpack/rspack builders,
swapping to use, droppinges-toolkitinstead oflodash-eslodash-es.I've also updated the migration docs to recommend using it rather than lodash template.-> e70ef00