-
-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove InternalsVisibleTo conditions in BlazorUI project file (#9495) #9496
Remove InternalsVisibleTo conditions in BlazorUI project file (#9495) #9496
Conversation
WalkthroughThe pull request modifies the Changes
Assessment against linked issues
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/BlazorUI/Bit.BlazorUI/Bit.BlazorUI.csproj (1)
Line range hint
67-86
: LGTM! Well-structured build tasks with proper incremental build supportThe build tasks are well-organized with:
- Clear input/output dependencies for incremental builds
- Proper sequencing of Node.js, JavaScript, and CSS tasks
- Configuration-specific handling (minification for Release)
Consider adding error handling for npm install failures:
<Target Name="InstallNodejsDependencies" Inputs="package.json" Outputs="node_modules\.package-lock.json"> - <Exec Command="npm install" StandardOutputImportance="high" StandardErrorImportance="high" /> + <Exec Command="npm install" StandardOutputImportance="high" StandardErrorImportance="high" IgnoreExitCode="false" /> </Target>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/BlazorUI/Bit.BlazorUI/Bit.BlazorUI.csproj
(1 hunks)
🔇 Additional comments (3)
src/BlazorUI/Bit.BlazorUI/Bit.BlazorUI.csproj (3)
Line range hint 8-12
: LGTM! Well-structured build process integration
The ResolveStaticWebAssetsInputsDependsOn property correctly integrates the new BeforeBuildTasks into the build pipeline for net9.0.
Line range hint 4-7
: LGTM! Clean multi-targeting configuration
The project configuration is well-structured with:
- Proper multi-targeting for net9.0 and net8.0
- Correct framework-specific package references
- Appropriate trimming and implicit using settings
Also applies to: 23-26
19-22
: Verify security implications of unconditional internal visibility
The removal of Debug/Release conditions means internal members are now always visible to Bit.BlazorUI.Extras
. Additionally, there are two InternalsVisibleTo entries with different public keys, which is unusual.
Let's verify the usage and necessity of both public keys:
Consider:
- Whether unconditional internal visibility aligns with security requirements
- If both public keys are necessary or if one can be removed
✅ Verification successful
Based on the gathered information, I can now provide the final response:
Unconditional internal visibility is appropriate in this context
The presence of both public keys in Bit.BlazorUI.csproj
is justified as Bit.BlazorUI.Extras
is a legitimate companion project that extends the main UI library's functionality, as evidenced by:
- Direct project reference in Bit.BlazorUI.Extras.csproj
- Extensive integration in demo projects and templates
- Shared build configuration and styling
The removal of Debug/Release conditions for InternalsVisibleTo is acceptable since:
- The projects are tightly coupled by design
- Bit.BlazorUI.Extras is part of the same trusted component suite
- The relationship between these projects is permanent, not configuration-dependent
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for references to Bit.BlazorUI.Extras to understand usage patterns
rg -l "Bit\.BlazorUI\.Extras" --type csproj
# Check if both public keys are actively used
rg -l "00240000048000009400000006020000002400005253413100040000010001008d726fe8" --type csproj
rg -l "002400000480000094000000060200000024000052534131000400000100010081a58360" --type csproj
Length of output: 328
Script:
#!/bin/bash
# Search for references to Bit.BlazorUI.Extras and public keys without file type restriction
rg -l "Bit\.BlazorUI\.Extras"
# Check if both public keys are actively used
rg -l "00240000048000009400000006020000002400005253413100040000010001008d726fe8"
rg -l "002400000480000094000000060200000024000052534131000400000100010081a58360"
# List all csproj files to understand project structure
fd ".+\.csproj$"
Length of output: 5762
Script:
#!/bin/bash
# Check the content of Bit.BlazorUI.Extras.csproj to verify signing configuration
cat "src/BlazorUI/Bit.BlazorUI.Extras/Bit.BlazorUI.Extras.csproj"
# Check if there were any previous conditions in git history
git log -p -- "src/BlazorUI/Bit.BlazorUI/Bit.BlazorUI.csproj" | grep -A 5 -B 5 "InternalsVisibleTo"
Length of output: 3759
closes #9495
Summary by CodeRabbit
New Features
Bug Fixes