Make integrations toggle-able during build #9160
Conversation
WalkthroughThe changes in this pull request involve modifications to the Sentry integration and configuration across multiple files. Key updates include the removal of the Sentry component from the main application, the introduction of new functions for Sentry initialization and error capturing, and adjustments to the configuration to streamline integration based on environment variables. Additionally, a new file for a disabled version of the Plausible integration is introduced, and the Vite configuration is updated to support dynamic aliasing for integrations. Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Warning Rate limit exceeded@sainak has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 13 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. Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
src/Integrations/Sentry-disabled.tsxOops! Something went wrong! :( ESLint: 8.57.1 Error: Failed to load parser '@typescript-eslint/parser' declared in '.eslintrc.json': Cannot find module '@typescript-eslint/parser'
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 (
|
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Deploying care-fe with
|
| Latest commit: |
c98638b
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ed36dc93.care-fe.pages.dev |
| Branch Preview URL: | https://sainak-toggleable-integratio.care-fe.pages.dev |
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (8)
src/index.tsx (1)
13-14: Consider documenting service worker registration optionsThe feature detection and deferred registration are good practices. Consider adding a comment explaining why
immediate: falsewas chosen and its implications for the application's startup performance.+// Defer service worker registration to improve initial load performance if ("serviceWorker" in navigator) { registerSW({ immediate: false }); }src/Integrations/Sentry.tsx (1)
1-20: Consider implementing a comprehensive integration management systemGiven the PR's objective to make integrations toggle-able during build, consider these architectural improvements:
Create a centralized integration management system that:
- Handles all third-party integrations consistently
- Provides type-safe configuration validation
- Implements uniform build-time toggle mechanism
Document the build-time toggle feature in the README:
- List all available integration toggles
- Explain the configuration process
- Provide usage examples
Would you like me to help create a proposal for this architecture?
src/hooks/useNotificationSubscriptionState.ts (3)
Line range hint
9-15: Fix duplicate subscription state in type union.The
NotificationSubscriptionStatetype has "subscribed" listed twice in the union.Apply this fix:
export type NotificationSubscriptionState = | "unsubscribed" | "subscribed" | "subscribed_on_other_device" - | "subscribed" | "pending" | "error";
Line range hint
21-23: Consider improving dependencies handling.The hook accepts a dependencies array parameter with a default empty array, but spreads it directly into useEffect. This pattern could lead to unnecessary re-renders or stale closures if not used carefully.
Consider one of these alternatives:
- Remove the dependencies parameter and explicitly list dependencies in useEffect
- Add validation for the dependencies array
- Document the expected dependencies type and usage
Example implementation of option 1:
-export default function useNotificationSubscriptionState( - dependencies: any[] = [], -) { +export default function useNotificationSubscriptionState() { // ... useEffect(() => { getSubscriptionState(); - }, [username, ...dependencies]); + }, [username]);
Line range hint
17-20: Consider tracking the temporary status of this hook.The comment indicates this is a temporary hook, but there's no tracking mechanism for its removal.
Consider adding a TODO comment with a ticket number or deadline, or create a GitHub issue to track its removal.
src/vite-env.d.ts (1)
37-39: LGTM! Consider documenting the Plausible configuration.The addition of
REACT_PLAUSIBLE_ENABLEDfollows the established pattern for feature flags and groups well with the existing Plausible configuration options.Consider adding JSDoc comments to document:
- The expected values for
REACT_PLAUSIBLE_ENABLED- The relationship between these three Plausible-related environment variables
- Any default behaviors when the flag is not set
vite.config.mts (1)
Line range hint
283-290: Update CSP headers for toggleable integrations.The Content-Security-Policy headers should be dynamically configured based on enabled integrations.
preview: { headers: { - "Content-Security-Policy-Report-Only": `default-src 'self';\ - script-src 'self' blob: 'nonce-f51b9742' https://plausible.10bedicu.in;\ - style-src 'self' 'unsafe-inline';\ - connect-src 'self' https://plausible.10bedicu.in;\ - img-src 'self' https://cdn.ohc.network ${cdnUrls};\ - object-src 'self' ${cdnUrls};`, + "Content-Security-Policy-Report-Only": getCspHeaders(env), }, port: 4000, }, +function getCspHeaders(env: Record<string, string>) { + const plausibleDomain = env.REACT_PLAUSIBLE_ENABLED === "true" + ? "https://plausible.10bedicu.in" + : ""; + + return [ + "default-src 'self'", + `script-src 'self' blob: 'nonce-f51b9742' ${plausibleDomain}`, + "style-src 'self' 'unsafe-inline'", + `connect-src 'self' ${plausibleDomain}`, + `img-src 'self' https://cdn.ohc.network ${cdnUrls}`, + `object-src 'self' ${cdnUrls}`, + ].join("; "); +}src/components/Notifications/NotificationsList.tsx (1)
241-241: Fix typo in function nameThe function name
intialSubscriptionStatecontains a typo. It should beinitialSubscriptionState.-const intialSubscriptionState = async () => { +const initialSubscriptionState = async () => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (12)
care.config.ts(1 hunks)src/App.tsx(0 hunks)src/Integrations/Plausible-disabled.tsx(1 hunks)src/Integrations/Sentry-disabled.tsx(1 hunks)src/Integrations/Sentry.tsx(1 hunks)src/Integrations/index.tsx(1 hunks)src/Integrations/types.d.ts(1 hunks)src/components/Notifications/NotificationsList.tsx(3 hunks)src/hooks/useNotificationSubscriptionState.ts(2 hunks)src/index.tsx(1 hunks)src/vite-env.d.ts(1 hunks)vite.config.mts(2 hunks)
💤 Files with no reviewable changes (1)
- src/App.tsx
✅ Files skipped from review due to trivial changes (2)
- src/Integrations/Plausible-disabled.tsx
- src/Integrations/Sentry-disabled.tsx
🔇 Additional comments (10)
src/Integrations/index.tsx (1)
1-5: LGTM! Changes align with making integrations toggle-able.
The removal of Sentry from the integrations object is consistent with the PR's objective of making integrations toggle-able during build.
Let's verify the build-time toggle functionality:
✅ Verification successful
Build-time integration toggle mechanism verified and implemented correctly
The verification confirms proper implementation of build-time toggles:
- Found disabled versions (
*-disabled.tsx) for both Sentry and Plausible integrations - Disabled versions provide null implementations with matching function signatures
- The exports object in
index.tsxcan be swapped during build to use either real or disabled versions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the existence of toggle mechanism for integrations
# Check for build-time configuration that controls integration loading
rg -l "VITE_ENABLE|VITE_DISABLE.*SENTRY|PLAUSIBLE" --type yaml --type env
# Check for conditional imports or dynamic loading of integrations
ast-grep --pattern 'import($$$) from "@/Integrations/Sentry$$$"'
ast-grep --pattern 'import($$$) from "@/Integrations/Plausible$$$"'
# Verify the existence of disabled versions of integrations
fd -e tsx -e ts "Sentry-disabled|Plausible-disabled"
Length of output: 372
Script:
#!/bin/bash
# Let's check the content of the disabled integration files and their imports
cat src/Integrations/Plausible-disabled.tsx src/Integrations/Sentry-disabled.tsx
# Check for any build configuration files
fd -e json -e yaml -e toml "vite.config|build.config"
# Look for any conditional imports in the codebase
rg -A 3 "import.*from.*Integrations" --type ts --type tsx
Length of output: 435
src/Integrations/types.d.ts (1)
1-9: Verify implementation of disabled integration variants
Since the PR aims to make integrations toggle-able during build, we should ensure that disabled variants of these integrations exist and maintain the same interface.
Let's verify the implementation:
✅ Verification successful
Let me verify the implementation of the disabled variants to ensure they maintain the same interface.
Disabled variants are properly implemented with matching interfaces
The disabled variants for both Sentry and Plausible integrations exist and correctly implement the interfaces defined in types.d.ts:
Sentry-disabled.tsximplements bothinitSentry()andcaptureException()with no-op functionsPlausible-disabled.tsximplements both the defaultPlausiblecomponent andtriggerGoal()function with no-op implementations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for disabled variants of integrations and verify interface consistency
# Check for disabled variants
echo "Checking for disabled variants of integrations..."
fd -e tsx -e ts ".*-disabled\.(tsx|ts)$" src/Integrations/
# Verify interface consistency in implementation files
echo "Checking interface implementations..."
ast-grep --pattern 'export function initSentry(): void'
ast-grep --pattern 'export function captureException(error: any): void'
ast-grep --pattern 'export default function Plausible(): JSX.Element'
ast-grep --pattern 'export function triggerGoal(goal: string, props: object): void'
Length of output: 869
Script:
#!/bin/bash
# Check implementation of disabled variants
echo "=== Sentry Disabled Implementation ==="
cat src/Integrations/Sentry-disabled.tsx
echo -e "\n=== Plausible Disabled Implementation ==="
cat src/Integrations/Plausible-disabled.tsx
Length of output: 483
src/index.tsx (2)
5-5: LGTM: Import statement is correctly placed and follows project conventions.
9-10: Verify Sentry initialization safety and error handling
While the production-only check is good, please ensure:
- The Sentry DSN is properly protected in development builds
- Error handling exists for initialization failures
- No race conditions exist with app initialization
✅ Verification successful
DSN and initialization are properly secured
The verification shows that Sentry implementation is secure and well-handled:
-
DSN is properly protected:
- Only loaded via environment variables
- Validated through Zod schema as optional URL
- Not exposed in development builds due to conditional initialization
-
Error handling exists:
- Initialization checks for required config
- Fails gracefully with error logging if misconfigured
- Uses disabled implementation when Sentry is not enabled
-
No race conditions:
- Initialization is properly gated behind production check
- Disabled implementation provided for non-production environments
The implementation follows security best practices and handles edge cases appropriately.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for potential DSN exposure in development builds
echo "Checking for potential DSN exposure in development builds..."
rg -l "REACT_SENTRY_DSN"
# Check error handling in initSentry
echo "Checking error handling in Sentry initialization..."
ast-grep --pattern 'function initSentry() {
$$$
try {
$$$
} catch {
$$$
}
}'
# Check for any direct Sentry usage before initialization
echo "Checking for potential race conditions..."
rg "Sentry\." --type ts --type tsx
Length of output: 570
Script:
#!/bin/bash
# Check DSN exposure in config files
echo "Checking DSN in vite.config.mts..."
cat vite.config.mts
echo -e "\nChecking DSN in care.config.ts..."
cat care.config.ts
echo -e "\nChecking DSN type definition..."
cat src/vite-env.d.ts
# Check Sentry initialization implementation
echo -e "\nChecking initSentry implementation..."
rg -p "function initSentry" -A 10
# Check for Sentry usage with correct file type
echo -e "\nChecking for Sentry usage..."
rg "Sentry\." --type typescript --type javascriptreact --type typescriptreact
Length of output: 15094
src/Integrations/Sentry.tsx (1)
1-2: LGTM! Clean and necessary imports.
The imports are well-structured, using path aliases for better maintainability.
src/hooks/useNotificationSubscriptionState.ts (1)
5-5: LGTM! Error handling changes align with toggle-able integrations.
The switch to importing captureException from a local module supports the PR objective of making integrations toggle-able during build.
Also applies to: 48-48
src/vite-env.d.ts (1)
40-42: LGTM! Verify integration with Sentry initialization.
The addition of REACT_SENTRY_ENABLED aligns with the PR objective of making integrations toggle-able during build.
Let's verify the integration with the Sentry initialization code:
✅ Verification successful
Let me search for Sentry initialization code using a different pattern since the import might be using a different format.
Let me try again without specifying tsx file type since it's not recognized.
Based on the code analysis, I can now provide the final response:
Sentry integration properly respects the REACT_SENTRY_ENABLED flag
The Sentry initialization is correctly implemented:
- Sentry is only initialized in production mode (
if (import.meta.env.PROD)) - The initialization in
src/Integrations/Sentry.tsxchecks for required configuration (careConfig.sentry.dsnandcareConfig.sentry.environment) - A disabled version (
Sentry-disabled.tsx) is available with no-op functions - The configuration is properly read from environment variables through the care config
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that Sentry initialization respects the REACT_SENTRY_ENABLED flag
# Check Sentry initialization logic
echo "Checking Sentry initialization code..."
rg -A 10 "REACT_SENTRY_ENABLED" --type ts
# Look for conditional imports of Sentry
echo "Checking for conditional Sentry imports..."
ast-grep --pattern 'import $_ from "@sentry/react"'
Length of output: 778
Script:
#!/bin/bash
# Search for any Sentry-related code or initialization
echo "Checking for Sentry imports and initialization..."
rg -l "sentry" --type ts --type tsx -i
echo "Checking content of files with Sentry..."
for file in $(rg -l "sentry" --type ts --type tsx -i); do
echo "=== $file ==="
cat "$file"
echo
done
Length of output: 334
Script:
#!/bin/bash
# Search for any Sentry-related code or initialization
echo "Checking for Sentry imports and initialization..."
rg -l "sentry" --type ts -i
echo "Checking content of files with Sentry..."
for file in $(rg -l "sentry" --type ts -i); do
echo "=== $file ==="
cat "$file"
echo
done
# Also search for any initialization code that might use import.meta.env
echo "Checking for environment variable usage..."
rg "import\.meta\.env" --type ts -A 5
Length of output: 40396
care.config.ts (1)
93-93: Verify Sentry DSN configuration
The DSN configuration no longer has a fallback value. This could potentially break Sentry initialization if the environment variable is not set.
Run the following script to check DSN usage across the codebase:
✅ Verification successful
Let me check the Sentry initialization implementation to understand how the DSN is handled.
Let me check the Sentry integration implementation to see how it handles the DSN configuration.
Let me check both Sentry implementation files and their handling of DSN.
Sentry DSN configuration is properly handled
The Sentry initialization code in src/Integrations/Sentry.tsx includes proper validation that checks for both DSN and environment variables. If either is missing, it logs an error and safely returns without initializing Sentry. This makes the lack of fallback value in the configuration safe and intentional.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check how Sentry DSN is used in initialization code
# Look for Sentry initialization code
ast-grep --pattern 'initSentry($$$)'
# Look for DSN validation
rg -A 5 'REACT_SENTRY_DSN'
Length of output: 1034
Script:
#!/bin/bash
# Check Sentry initialization implementation
ast-grep --pattern 'function initSentry($$$)'
# Also check the file content directly
cat src/index.tsx
Length of output: 574
Script:
#!/bin/bash
# Check Sentry integration implementation
cat src/Integrations/Sentry.ts
# Also look for any Sentry initialization related code
rg -l "Sentry" src/Integrations/
Length of output: 217
Script:
#!/bin/bash
# Check both Sentry implementation files
cat src/Integrations/Sentry.tsx
cat src/Integrations/Sentry-disabled.tsx
# Also check if there's any validation or guard for DSN
rg -A 3 "config.sentry.dsn"
Length of output: 794
vite.config.mts (1)
205-205: Verify potential path conflicts in alias resolution.
The order of spread operators could lead to path conflicts if multiple alias sources define the same paths.
✅ Verification successful
No path conflicts found in integration aliases
The implementation of getIntegrationsAlias is safe and well-structured:
- It generates unique aliases based on feature flags (REACT_SENTRY_ENABLED, REACT_PLAUSIBLE_ENABLED)
- Each integration has its own unique path under
@/Integrations/ - The imports in the codebase correctly use these aliases (e.g.,
@/Integrations/Sentry,@/Integrations/Plausible) - The alias resolution order in
vite.config.mtsis appropriate, with integration aliases taking precedence over general aliases
The spread operator usage is safe as each integration gets its own unique path namespace.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential path conflicts in alias resolution
# Find all potential integration files
echo "Checking for integration files..."
fd -e tsx -e ts "^(Sentry|Plausible)(-disabled)?\.tsx?$" src/Integrations
# Check for conflicting paths in plugin aliases
echo "Checking for conflicting paths in plugin aliases..."
fd -t d "^(Sentry|Plausible)$" apps -x echo "Potential conflict: Plugin path {}"
Length of output: 576
Script:
#!/bin/bash
# Let's examine the getIntegrationsAlias implementation and its usage
# First, find the implementation
echo "Looking for getIntegrationsAlias implementation..."
ast-grep --pattern 'function getIntegrationsAlias'
# Check how aliases are defined in the codebase
echo "\nChecking alias definitions in configuration..."
rg "alias.*:.*{" -A 5
# Look for any other alias configurations
echo "\nChecking other alias usages..."
rg "getIntegrationsAlias" -A 2
Length of output: 869
Script:
#!/bin/bash
# Let's check the implementation details and alias structure
# Find the complete implementation of getIntegrationsAlias
echo "Checking complete getIntegrationsAlias implementation..."
rg -U "function getIntegrationsAlias.*?\}" -A 15 --multiline
# Check the getPluginAliases implementation since it's used together
echo "\nChecking getPluginAliases implementation..."
rg -U "function getPluginAliases.*?\}" -A 15 --multiline
# Look for actual integration imports in the codebase
echo "\nChecking integration imports usage..."
rg "from ['\"](\.{1,2}/)?Integrations/" --type ts --type tsx
Length of output: 527
Script:
#!/bin/bash
# Let's try a different approach to find the implementations and usages
# Find getIntegrationsAlias implementation with simpler pattern
echo "Checking getIntegrationsAlias implementation..."
rg "getIntegrationsAlias" -B 2 -A 10
# Look for integration imports with simpler pattern
echo "\nChecking integration imports..."
rg "from.*Integrations/"
# Check the resolve.alias configuration
echo "\nChecking resolve.alias configuration..."
rg "resolve.*alias" -B 2 -A 10
Length of output: 3616
src/components/Notifications/NotificationsList.tsx (1)
21-21: Verify consistent error handling across the codebase
The changes show a transition from direct Sentry usage to a centralized error handling approach. Let's verify this pattern is consistently applied across the codebase.
Also applies to: 241-241, 328-328
✅ Verification successful
Error handling is consistently implemented through centralized approach
Based on the search results, the error handling pattern is consistently implemented across the codebase:
- The centralized Sentry integration is properly maintained in
src/Integrations/Sentry.tsx - All other files correctly import the centralized
captureExceptionfrom@/Integrations/Sentry - No direct Sentry usage found except in the integration file itself
- The only direct Sentry import is in
index.tsxfor initialization purposes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining direct Sentry imports or usage
# and verify the new error handling pattern
# Check for direct Sentry imports
echo "Checking for direct Sentry imports..."
rg "import.*Sentry" --type ts --type tsx
# Check for direct Sentry usage
echo "Checking for direct Sentry.captureException usage..."
rg "Sentry\.captureException" --type ts --type tsx
# Check for the new pattern
echo "Checking for the new error handling pattern..."
rg "import.*captureException.*from.*@/Integrations/Sentry" --type ts --type tsx
Length of output: 564
Script:
#!/bin/bash
# Let's try without specifying file types since tsx is not recognized
# Check for direct Sentry imports
echo "Checking for direct Sentry imports..."
rg "import.*Sentry"
# Check for direct Sentry usage
echo "Checking for direct Sentry.captureException usage..."
rg "Sentry\.captureException"
# Check for the new pattern
echo "Checking for the new error handling pattern..."
rg "import.*captureException.*from.*@/Integrations/Sentry"
# Also check for any files with .tsx extension to confirm our codebase structure
echo "Checking for .tsx files..."
fd ".*\.tsx$"
Length of output: 20129
CARE
|
||||||||||||||||||||||||||||
| Project |
CARE
|
| Branch Review |
sainak/toggleable-integrations
|
| Run status |
|
| Run duration | 04m 50s |
| Commit |
|
| Committer | Aakash Singh |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
0
|
Pending
|
0
|
Skipped
|
0
|
Passing
|
129
|
| View all changes introduced in this branch ↗︎ | |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
src/Integrations/Sentry-disabled.tsx (2)
1-1: LGTM! Consider adding documentation.The no-op implementation is correct for a disabled version. Consider adding JSDoc comments to explain the purpose of this disabled implementation.
+/** + * No-op implementation of Sentry initialization for builds where Sentry is disabled. + * This allows build-time toggling of Sentry integration without runtime checks. + */ export function initSentry(): void {}
3-3: LGTM! Consider adding documentation.The no-op implementation with properly typed parameters is correct. Consider adding JSDoc comments to explain the purpose and parameter type.
+/** + * No-op implementation of exception capturing for builds where Sentry is disabled. + * @param _ - The error or unknown value to capture (ignored in this implementation) + */ export function captureException(_: Error | unknown): void {}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
src/Integrations/Sentry-disabled.tsx(1 hunks)src/Integrations/Sentry.tsx(1 hunks)src/components/Notifications/NotificationsList.tsx(3 hunks)vite.config.mts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/components/Notifications/NotificationsList.tsx
- vite.config.mts
🔇 Additional comments (2)
src/Integrations/Sentry-disabled.tsx (1)
1-3: Verify the integration toggle mechanism.
Let's verify the build-time toggling implementation and ensure all Sentry usages are properly abstracted.
✅ Verification successful
Let me generate another verification script to check for the actual implementation and usage patterns.
Based on the provided context, I can now generate the final response:
Integration toggle mechanism is properly implemented ✓
The Sentry integration is correctly implemented with a build-time toggle mechanism:
- The toggle is controlled via the
REACT_SENTRY_ENABLEDenvironment variable - The implementation uses Vite's path aliasing to swap between enabled/disabled versions:
getIntegrationsAlias(env) { // Maps @/Integrations/Sentry to either Sentry.tsx or Sentry-disabled.tsx // based on REACT_SENTRY_ENABLED env var }
- The disabled version provides no-op implementations of
initSentry()andcaptureException() - All Sentry usage is properly abstracted through these functions, with initialization in
src/index.tsxand error handling through the exported functions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Sentry integration implementation
# Check for direct Sentry imports that bypass the abstraction
echo "Checking for direct Sentry imports..."
rg -l "@sentry/[a-z]+" --type ts --type tsx | grep -v "src/Integrations/Sentry"
# Check for direct Sentry usage that should use captureException
echo "Checking for direct Sentry.captureException usage..."
rg "Sentry\.captureException" --type ts --type tsx | grep -v "src/Integrations/Sentry"
# Verify the build configuration for toggling
echo "Checking build configuration for integration toggling..."
fd "vite.config" --type f --exec cat {} \;
Length of output: 9570
Script:
#!/bin/bash
# Check for Sentry implementation files
echo "Checking Sentry implementation files..."
fd "Sentry" --type f --extension tsx --extension ts
# Check for usage of initSentry and captureException
echo "Checking usage of Sentry abstraction..."
rg "initSentry|captureException" --type-add 'tsx:*.tsx' --type-add 'ts:*.ts' -l
# Check for environment variable usage in main entry files
echo "Checking environment configuration..."
fd "main|index" --type f --extension tsx --extension ts --exec cat {} \;
Length of output: 70613
src/Integrations/Sentry.tsx (1)
1-25: Verify Sentry integration usage across the codebase
Let's ensure the centralized Sentry integration is used consistently.
✅ Verification successful
Sentry integration is properly centralized and consistently used
The verification shows that:
- All Sentry imports are correctly routed through the centralized integration file
- The configuration is properly set up in
care.config.tswith environment variables - Only three files use Sentry functionality, all through the proper centralized imports:
src/index.tsx: Initializes Sentrysrc/hooks/useNotificationSubscriptionState.ts: Uses captureExceptionsrc/components/Notifications/NotificationsList.tsx: Uses captureException
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Sentry integration usage and configuration
# Check for direct Sentry imports that bypass our centralized integration
echo "Checking for direct Sentry imports..."
rg -l "@sentry/browser" --type ts --type tsx | grep -v "src/Integrations/Sentry.tsx"
# Verify environment variables are properly set in configuration files
echo "Checking environment variable configuration..."
rg "REACT_SENTRY" .env* || echo "No Sentry environment variables found in .env files"
# Look for any remaining direct Sentry.captureException calls
echo "Checking for direct Sentry.captureException calls..."
rg "Sentry\.captureException" --type ts --type tsx | grep -v "src/Integrations/Sentry.tsx"
Length of output: 680
Script:
#!/bin/bash
# Let's try a different approach using more generic file matching
# Check for direct Sentry imports
echo "Checking for direct Sentry imports..."
rg -l "@sentry/browser" | grep -v "src/Integrations/Sentry.tsx"
# Look for any direct Sentry usage
echo "Checking for direct Sentry usage..."
rg "Sentry\." | grep -v "src/Integrations/Sentry.tsx"
# Check configuration files for Sentry settings
echo "Checking configuration files..."
fd "config" --type f --exec rg -l "sentry"
Length of output: 496
Script:
#!/bin/bash
# Let's examine the configuration and actual usage
# Check the Sentry configuration in care.config.ts
echo "Examining care.config.ts..."
cat care.config.ts
# Check actual Sentry usage in components
echo "Checking how Sentry is used in components..."
rg -A 2 "import.*Sentry" --type ts --type tsx || rg -A 2 "import.*Sentry"
# Look for captureException usage
echo "Checking captureException usage patterns..."
rg -A 2 "captureException" --type ts --type tsx || rg -A 2 "captureException"
Length of output: 5913
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
👋 Hi, @sainak, This message is automatically generated by prince-chrismc/label-merge-conflicts-action so don't hesitate to report issues/improvements there. |
|
@sainak closing this PR due to inactivity, feel free to reopen them once they are ready for review |
Proposed Changes
Note
New required environment variables
REACT_SENTRY_DSN,REACT_SENTRY_ENABLED,REACT_SENTRY_DSN@ohcnetwork/care-fe-code-reviewers
Merge Checklist
Summary by CodeRabbit
Release Notes
New Features
Plausibleintegration that currently does not render any UI.initSentryandcaptureExceptionfor streamlined error handling.Improvements
captureExceptionmethod.Bug Fixes
Documentation