fix: don't hard-fail on unresolvable hook-contributed client bundle icons#504
Conversation
…cons Icons contributed by modules through the `icon:clientBundleIcons` hook were treated as hard build failures when they couldn't be resolved (collection not installed, or a name that doesn't exist / is version-skewed), even though scanned icons in the exact same situation already fall back to runtime loading. Only icons the user explicitly listed in `clientBundle.icons` now hard-fail the build. Scanned and hook-contributed icons are best-effort: dropped from the bundle and resolved at runtime instead. Hook-contributed icons are collected separately and warned about (without throwing), since - unlike scanned icons - they aren't subject to extraction false positives.
commit: |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthrough
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/context.ts`:
- Around line 244-255: The icon resolution loop in the bundle-building logic
still treats hook-contributed icons as fatal when an exception is thrown after
the `!data` branch. Update the `catch` path to mirror the existing best-effort
handling: only add explicitly user-listed icons to `failed`, and route
hook-contributed or scanned icons to `dropped` so they fall back to runtime
loading. Keep the same `userIcons.has(icon)` and `this.scannedIcons.has(icon)`
checks consistent between the success and exception paths.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e6795ac0-d3a9-4ec7-a719-37e9d4e28cf5
📒 Files selected for processing (3)
src/bundle-client.tssrc/context.tstest/client-bundle.test.ts
The icon resolution loop's catch block unconditionally pushed to `failed`, so an exception thrown during resolution (e.g. `loadCollectionFromFS` rejecting on a corrupt/version-skewed `icons.json`) hard-failed the build even for scanned and hook-contributed icons. Mirror the best-effort handling from the `!data` branch: only explicit user icons hard-fail, scanned/hook icons fall back to runtime.
📚 Description
Icons contributed by modules through the
icon:clientBundleIconshook hard-failed the build when they couldn't be resolved, even though scanned icons in the same situation already fall back to runtime loading.Now only icons explicitly listed in
clientBundle.iconshard-fail. Scanned and hook-contributed icons are best-effort; unresolvable hook icons are warned about rather than thrown.This unblocks nuxt/ui#6633, which can now drop its filesystem collection-presence check and rely on @nuxt/icon to skip whatever it can't resolve.
Test
Extended
test/client-bundle.test.ts: a hook-contributed icon whose collection/name can't be resolved is omitted rather than throwing, while an unresolvable icon inclientBundle.iconsstill fails the build.