-
Notifications
You must be signed in to change notification settings - Fork 2
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
chore: Added dev dashboard #1381
Conversation
📝 WalkthroughWalkthroughThe pull request includes significant updates to the Changes
Possibly related PRs
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
Documentation and Community
|
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: 5
🧹 Outside diff range and nitpick comments (9)
data/homepage/config/bookmarks.yaml (1)
1-4
: Consider adding a brief description of the file's purpose.While the reference to the documentation is helpful, it would be beneficial to add a brief comment explaining that this file configures bookmarks for the development dashboard.
--- # For configuration options and examples, please see: # https://gethomepage.dev/configs/bookmarks +# Purpose: Configures quick access bookmarks for the development dashboard
data/homepage/config/services.yaml (1)
1-4
: Consider enhancing the configuration header documentation.While the link to the documentation is helpful, consider adding:
- A brief description of what this configuration file does
- Any environment-specific considerations
- Security notes about these development services
--- # For configuration options and examples, please see: # https://gethomepage.dev/configs/services +# +# This configuration defines development services available in the local environment. +# Note: These services are intended for development use only and should not be exposed in production.compose.yml (2)
55-55
: Enhance service documentationWhile the comment is helpful, consider making it more descriptive by including:
- The purpose of RedisInsight (GUI tool for Redis database management)
- Any authentication requirements
- Port information
Consider updating the comment to:
- # GUI for checking what's in Redis + # RedisInsight - Web-based GUI for Redis database management + # Accessible at http://redisinsight.localhost:8080Also applies to: 68-69
Line range hint
1-300
: Consider architectural improvements for better reliability and securitySeveral architectural improvements could enhance the system:
Restart Policies:
homepage
usesunless-stopped
bff
usesalways
- Other services have no explicit policy
Consider standardizing restart policies across services.Service Dependencies:
- Some services might need explicit
depends_on
configurations- Consider adding health checks for all dependent services
Network Isolation:
- Consider using custom networks to isolate service groups
- Limit inter-service communication to only required paths
Would you like me to provide specific configuration examples for these improvements?
homarr-config.json (5)
6-6
: Consider organizing apps into categoriesThe empty categories array could be utilized to group related tools (e.g., "Databases", "Documentation", "Development Tools"), making the dashboard more organized and easier to navigate.
17-18
: Consider extracting common configurationThe network status codes and behavior settings are duplicated across all apps. Consider extracting these into a common configuration to improve maintainability.
Example structure:
{ "defaultAppConfig": { "network": { "enabledStatusChecker": true, "statusCodes": ["200", "301", "302", "304", "307", "308"] }, "behaviour": { "isOpeningNewTab": true } } }Also applies to: 37-39
363-371
: Resolve inconsistent timezone configurationThe widget has
enableTimezone: false
but includes timezone location data for Paris. Either:
- Enable timezone display if Paris time is needed, or
- Remove the unused timezone location data if timezone display is not needed
434-437
: Use precise color codes instead of basic color namesReplace basic color names with specific hex codes or RGB values for consistent appearance:
"colors": { - "primary": "red", - "secondary": "yellow", + "primary": "#FF0000", + "secondary": "#FFFF00", "shade": 7 }
415-418
: Consider adding alternative search enginesThe search configuration is limited to Google. Consider adding support for alternative search engines (e.g., DuckDuckGo, Bing) to provide user choice.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (7)
data/homepage/icons/GraphQL.svg
is excluded by!**/*.svg
data/homepage/icons/docusaurus.png
is excluded by!**/*.png
data/homepage/icons/nodejs.png
is excluded by!**/*.png
data/homepage/icons/react_logo.png
is excluded by!**/*.png
data/homepage/icons/redis.jpg
is excluded by!**/*.jpg
data/homepage/icons/storybook.svg
is excluded by!**/*.svg
data/homepage/icons/traefik.png
is excluded by!**/*.png
📒 Files selected for processing (8)
compose.yml
(3 hunks)data/homepage/config/bookmarks.yaml
(1 hunks)data/homepage/config/docker.yaml
(1 hunks)data/homepage/config/kubernetes.yaml
(1 hunks)data/homepage/config/services.yaml
(1 hunks)data/homepage/config/settings.yaml
(1 hunks)data/homepage/config/widgets.yaml
(1 hunks)homarr-config.json
(1 hunks)
✅ Files skipped from review due to trivial changes (4)
- data/homepage/config/docker.yaml
- data/homepage/config/kubernetes.yaml
- data/homepage/config/settings.yaml
- data/homepage/config/widgets.yaml
🔇 Additional comments (4)
data/homepage/config/bookmarks.yaml (1)
5-20
: Verify URL accessibility and consider adding more resources.
Let's verify the URLs and consider adding more commonly used development resources.
Consider adding these commonly used resources if they're relevant:
- Development environment URL
- API documentation
- Monitoring/logging dashboards
✅ Verification successful
All URLs are accessible and repository references are complete
All configured URLs return HTTP 200 status codes, confirming they are accessible. The GitHub repository search shows that all relevant dialog-related repositories are already included in the bookmarks. The current set of resources provides good coverage of essential development links.
While the suggestion to add development environment, API documentation, and monitoring dashboards is valid, this should be left to the team's discretion based on their specific needs and access patterns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify accessibility of configured URLs and search for potential missing resources
# Extract and verify URLs
echo "Verifying configured URLs..."
urls=(
"https://af.at.altinn.cloud/"
"https://github.com/digdir/dialogporten-frontend"
"https://github.com/digdir/dialogporten"
"https://github.com/digdir/designsystemet"
"https://docs.altinn.studio/dialogporten/"
)
for url in "${urls[@]}"; do
curl -s -o /dev/null -w "%{http_code}" "$url"
done
# Search for potential missing repository references
echo "Searching for other commonly referenced repositories..."
gh repo list digdir --json name,url --limit 100 | \
jq -r '.[] | select(.name | contains("dialog") or contains("altinn"))'
Length of output: 1251
data/homepage/config/services.yaml (2)
24-27
:
Review security implications of exposed GraphIQL endpoint.
GraphIQL is a powerful development tool that could expose sensitive schema information. Ensure it's properly secured in development.
Consider implementing authentication or removing it if not needed. Also verify if GraphIQL is enabled in the BFF configuration:
✅ Verification successful
Let me search for any GraphQL/GraphiQL related configurations in the codebase to better understand how it's set up and secured.
GraphiQL endpoint is secured through token verification
The GraphiQL interface is properly secured:
- It's protected by the same token verification middleware as the GraphQL API
- Token verification is enforced through
fastify.verifyToken()
inpackages/bff/src/graphql/api.ts
- GraphiQL is only enabled when
ENABLE_GRAPHIQL
env variable is true (configurable)
The exposed endpoint in the services configuration is safe to keep as it inherits these security controls.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if GraphIQL is configured in BFF
rg -l "graphiql.*=.*true" --type js --type ts
Length of output: 47
Script:
#!/bin/bash
# Search for GraphiQL configuration patterns more broadly
rg -i "graphi[q]?l" --type=yaml --type=js --type=ts -A 3 -B 3
# Also check for any Apollo Server or GraphQL middleware setup
rg -i "apollo.*server|graphql.*middleware" --type=js --type=ts -A 3 -B 3
# Look for potential GraphQL endpoint configurations
rg -i "graphql.*endpoint|graphql.*path" --type=js --type=ts --type=yaml -A 3 -B 3
Length of output: 8756
5-43
: Verify resource availability and accessibility.
Need to verify:
- Icon file existence
- Service URL accessibility
homarr-config.json (1)
213-214
: Verify pgAdmin4 configuration
The pgAdmin4 service might require additional configuration to connect to the PostgreSQL database. Ensure that the database connection parameters are properly configured in the pgAdmin4 service.
Also applies to: 234-235
- Developer: | ||
- Dialogporten Prod: | ||
- abbr: DP Prod | ||
href: https://af.at.altinn.cloud/ | ||
- Github Arbeidsflate: | ||
- abbr: GH AF | ||
href: https://github.com/digdir/dialogporten-frontend | ||
- Github Dialogporten: | ||
- abbr: GH DP | ||
href: https://github.com/digdir/dialogporten | ||
- Github Designsystem: | ||
- abbr: GH DS | ||
href: https://github.com/digdir/designsystemet | ||
- Dialogporten Altinn Docs: | ||
- abbr: DP Docs | ||
href: https://docs.altinn.studio/dialogporten/ |
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.
🛠️ Refactor suggestion
Fix YAML indentation for consistency.
The indentation is inconsistent throughout the file. YAML best practices recommend using 2 spaces for indentation.
- Developer:
- - Dialogporten Prod:
- - abbr: DP Prod
- href: https://af.at.altinn.cloud/
+ - Dialogporten Prod:
+ - abbr: DP Prod
+ href: https://af.at.altinn.cloud/
Committable suggestion skipped: line range outside the PR's diff.
- Database: | ||
- PgAdmin: | ||
href: http://pgadmin4.localhost/ | ||
icon: /icons/pgadmin.svg | ||
description: PgAdmin | ||
- RedisInsight: | ||
href: http://redisinsight.localhost/ | ||
icon: /icons/redis.jpg | ||
description: RedisInsight | ||
|
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.
Secure database management tools access.
PgAdmin and RedisInsight provide direct database access. This could pose security risks if not properly configured.
Consider:
- Implementing authentication
- Restricting access to specific IP ranges
- Disabling these tools in shared development environments
homepage: | ||
image: ghcr.io/gethomepage/homepage:latest | ||
container_name: homepage | ||
environment: | ||
PUID: 1000 | ||
PGID: 1000 | ||
volumes: | ||
- ./data/homepage/config:/app/config | ||
- ./data/homepage/icons:/app/public/icons | ||
- ./var/run/docker.sock:/var/run/docker.sock:ro | ||
restart: unless-stopped | ||
labels: | ||
- "traefik.enable=true" | ||
- "traefik.http.routers.dave.rule=Host(`localhost`)" | ||
volumes: | ||
- /var/run/docker.sock:/var/run/docker.sock | ||
- "traefik.http.routers.homepage.rule=Host(`localhost`)" | ||
ports: | ||
- 3000:3000 |
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.
Security and reliability concerns in homepage service configuration
Several issues need attention:
- Using the
latest
tag can lead to unexpected behavior and breaks reproducibility - Hardcoded PUID/PGID values should be configurable
- Mounting Docker socket poses security risks
- Missing healthcheck unlike other services
Consider applying these improvements:
homepage:
- image: ghcr.io/gethomepage/homepage:latest
+ image: ghcr.io/gethomepage/homepage:v0.8.7 # Use specific version
container_name: homepage
environment:
- PUID: 1000
- PGID: 1000
+ PUID: ${PUID:-1000}
+ PGID: ${PGID:-1000}
volumes:
- ./data/homepage/config:/app/config
- ./data/homepage/icons:/app/public/icons
- - ./var/run/docker.sock:/var/run/docker.sock:ro
+ # Consider removing Docker socket mount or implementing least privilege
restart: unless-stopped
+ healthcheck:
+ test: ["CMD", "wget", "--spider", "http://localhost:3000"]
+ interval: 30s
+ timeout: 10s
+ retries: 3
labels:
- "traefik.enable=true"
- "traefik.http.routers.homepage.rule=Host(`localhost`)"
ports:
- 3000:3000
📝 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.
homepage: | |
image: ghcr.io/gethomepage/homepage:latest | |
container_name: homepage | |
environment: | |
PUID: 1000 | |
PGID: 1000 | |
volumes: | |
- ./data/homepage/config:/app/config | |
- ./data/homepage/icons:/app/public/icons | |
- ./var/run/docker.sock:/var/run/docker.sock:ro | |
restart: unless-stopped | |
labels: | |
- "traefik.enable=true" | |
- "traefik.http.routers.dave.rule=Host(`localhost`)" | |
volumes: | |
- /var/run/docker.sock:/var/run/docker.sock | |
- "traefik.http.routers.homepage.rule=Host(`localhost`)" | |
ports: | |
- 3000:3000 | |
homepage: | |
image: ghcr.io/gethomepage/homepage:v0.8.7 # Use specific version | |
container_name: homepage | |
environment: | |
PUID: ${PUID:-1000} | |
PGID: ${PGID:-1000} | |
volumes: | |
- ./data/homepage/config:/app/config | |
- ./data/homepage/icons:/app/public/icons | |
# Consider removing Docker socket mount or implementing least privilege | |
restart: unless-stopped | |
healthcheck: | |
test: ["CMD", "wget", "--spider", "http://localhost:3000"] | |
interval: 30s | |
timeout: 10s | |
retries: 3 | |
labels: | |
- "traefik.enable=true" | |
- "traefik.http.routers.homepage.rule=Host(`localhost`)" | |
ports: | |
- 3000:3000 |
- "homarr.relativeSubdomain=dashboard" | ||
- "homarr.icon=simple-icons:traefikproxy" |
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.
💡 Codebase verification
Inconsistent service label naming scheme needs standardization
The verification confirms inconsistent label naming across services in compose.yml
:
- Services using "homarr" prefix:
- dashboard (lines 21-22)
- redisinsight (confirmed in output)
- Services still using "dave" prefix:
- pgadmin4
- app (used twice)
- storybook
- docs
All service labels should follow the same naming scheme for consistency. Please update all remaining "dave" prefixed labels to use "homarr" prefix to maintain a uniform configuration.
🔗 Analysis chain
Inconsistent label naming across services
The labels have been updated from "dave" to "homarr" here, but this change hasn't been applied consistently across all services (e.g., pgadmin4, bff, frontend, storybook, and docs services still use "dave" labels).
Let's verify the inconsistency:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find all service labels to verify naming consistency
rg "dave\." compose.yml
rg "homarr\." compose.yml
Length of output: 652
homarr-config.json
Outdated
}, | ||
{ | ||
"id": "755d6f85-f5c1-426e-b108-8eb72ed61c25", | ||
"name": "Traefik", | ||
"url": "http://dashboard.localhost", | ||
"appearance": { | ||
"iconUrl": "https://cdn.jsdelivr.net/gh/walkxcode/dashboard-icons/svg/traefik-proxy.svg", | ||
"appNameStatus": "normal", | ||
"positionAppName": "column", | ||
"lineClampAppName": 1, | ||
"appNameFontSize": 16 | ||
}, | ||
"network": { | ||
"enabledStatusChecker": true, | ||
"statusCodes": [ | ||
"200", | ||
"301", | ||
"302", | ||
"304", | ||
"307", | ||
"308" | ||
] | ||
}, | ||
"behaviour": { | ||
"isOpeningNewTab": true, | ||
"externalUrl": "http://dashboard.localhost" | ||
}, | ||
"area": { | ||
"type": "wrapper", | ||
"properties": { | ||
"id": "default" | ||
} | ||
}, | ||
"shape": { | ||
"lg": { | ||
"location": { | ||
"x": 6, | ||
"y": 0 | ||
}, | ||
"size": { | ||
"width": 1, | ||
"height": 1 | ||
} | ||
} | ||
}, | ||
"integration": { | ||
"type": null, | ||
"properties": [] | ||
} | ||
}, | ||
{ | ||
"id": "1822917e-8c87-498a-bb95-79253a894cff", | ||
"name": "Arbeidsflate", | ||
"url": "http://app.localhost", | ||
"appearance": { | ||
"iconUrl": "/imgs/logo/logo.png", | ||
"appNameStatus": "normal", | ||
"positionAppName": "column", | ||
"lineClampAppName": 1, | ||
"appNameFontSize": 16 | ||
}, | ||
"network": { | ||
"enabledStatusChecker": true, | ||
"statusCodes": [ | ||
"200", | ||
"301", | ||
"302", | ||
"304", | ||
"307", | ||
"308" | ||
] | ||
}, | ||
"behaviour": { | ||
"isOpeningNewTab": true, | ||
"externalUrl": "http://app.localhost" | ||
}, | ||
"area": { | ||
"type": "wrapper", | ||
"properties": { | ||
"id": "default" | ||
} | ||
}, | ||
"shape": { | ||
"lg": { | ||
"location": { | ||
"x": 0, | ||
"y": 0 | ||
}, | ||
"size": { | ||
"width": 1, | ||
"height": 1 | ||
} | ||
} | ||
}, | ||
"integration": { | ||
"type": null, | ||
"properties": [] | ||
} | ||
} | ||
], |
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.
Review security implications of HTTP usage and guest access
Several security considerations:
- All services use HTTP instead of HTTPS
- Combined with
allowGuests: true
(line 450), this could expose sensitive development tools
Consider:
- Using HTTPS for local development
- Implementing authentication for sensitive tools (e.g., PostgreSQL, Redis)
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
🧹 Outside diff range and nitpick comments (4)
packages/frontend/src/components/PartyDropdown/PartyDropdown.tsx (1)
36-36
: LGTM! Consider enhancing readability with destructuring.The conditional expression is correct and properly handles the null/undefined case. For slightly better readability, you could consider destructuring
selectedParties
at the top of the component.export const PartyDropdown = forwardRef((props: PartyDropdownProps, ref: Ref<PartyDropdownRef>) => { const { counterContext } = props; const [isMenuOpen, setIsMenuOpen] = useState<boolean>(false); const { t } = useTranslation(); + const { selectedParties, allOrganizationsSelected, parties } = useParties(); - const { selectedParties, allOrganizationsSelected, parties } = useParties();packages/frontend/src/components/Header/SearchBar.tsx (3)
54-54
: Consider optimizing the effect's dependency.While changing to
searchParams
is correct for tracking URL parameter changes, it might cause unnecessary re-renders sincesearchParams
is a new object on every render.Consider using a more specific dependency:
- }, [searchParams]); + }, [searchParams.get('search')]);
Line range hint
48-54
: Enhance effect implementation to prevent potential issues.The current effect implementation has room for improvement:
- The early return might skip cleanup of the search value
- The URL parameter deletion is redundant when there's no search param
Consider this improved implementation:
useEffect(() => { const searchBarParam = new URLSearchParams(searchParams); + const searchValue = searchBarParam.get('search'); - if (searchBarParam.get('search')) { - return; - } - setSearchValue(''); - searchBarParam.delete('search'); + setSearchValue(searchValue || ''); + + // Only update URL if needed to prevent unnecessary history entries + if (!searchValue && searchBarParam.has('search')) { + searchBarParam.delete('search'); + setSearchParams(searchBarParam, { replace: true }); + } }, [searchParams.get('search')]);
Line range hint
13-54
: Consider consolidating state management.The component currently maintains multiple sources of truth for the search state:
- URL search params (
searchParams
)- Context state (
searchString
)- Local state (
searchValue
)This could lead to synchronization issues and unnecessary complexity.
Consider these improvements:
- Use URL as the single source of truth:
const SearchBar: React.FC = () => { const [searchParams, setSearchParams] = useSearchParams(); const searchValue = searchParams.get('search') || ''; const setSearch = (value: string) => { const newParams = new URLSearchParams(searchParams); if (value) { newParams.set('search', value); } else { newParams.delete('search'); } setSearchParams(newParams, { replace: true }); }; // Rest of the component using searchValue and setSearch };
- Or if context is needed, derive it from URL:
const useSearchState = () => { const [searchParams, setSearchParams] = useSearchParams(); return { searchValue: searchParams.get('search') || '', setSearch: (value: string) => { const newParams = new URLSearchParams(searchParams); if (value) { newParams.set('search', value); } else { newParams.delete('search'); } setSearchParams(newParams, { replace: true }); } }; };This would:
- Eliminate state synchronization issues
- Reduce complexity
- Make the component more predictable
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (4)
homarr-config.json
(1 hunks)packages/frontend/src/components/Activity/Activity.tsx
(1 hunks)packages/frontend/src/components/Header/SearchBar.tsx
(1 hunks)packages/frontend/src/components/PartyDropdown/PartyDropdown.tsx
(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- homarr-config.json
🔇 Additional comments (1)
packages/frontend/src/components/Activity/Activity.tsx (1)
38-38
: LGTM! The simplified nullish coalescing improves readability.
The removal of parentheses maintains the same functionality while making the code more concise. The nullish coalescing operators properly handle undefined/null cases for both company and person scenarios.
Let's verify the nullish coalescing behavior across different scenarios:
✅ Verification successful
Nullish coalescing pattern is consistently applied across the codebase
The verification shows that:
- The nullish coalescing pattern with empty string fallback (
?? ''
) is consistently used across the codebase forserviceOwner.name
serviceOwner?.name
optional chaining is used consistently in similar contexts- The pattern matches the implementation in Activity.tsx, confirming the change aligns with the codebase conventions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent null handling patterns across the codebase
# Look for similar patterns to ensure consistent null handling
# Search for similar nullish coalescing patterns in the codebase
rg "(\?\?.*''|\?\?.*\"\")" --type typescript
# Look for potential edge cases in serviceOwner usage
ast-grep --pattern 'serviceOwner?.$_'
Length of output: 747
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
🧹 Outside diff range and nitpick comments (1)
package.json (1)
9-10
: Consider consolidating Biome scripts for clarityThe addition of
biome:fix
complements the existingbiome:fix-staged
script, but their naming and purpose might need clarification:
biome:fix-staged
: Checks and fixes only staged filesbiome:fix
: Formats all files in the projectConsider renaming these scripts for better clarity:
- "biome:fix-staged": "pnpm husky check --staged --fix", - "biome:fix": "pnpm biome format --write" + "biome:format-staged": "pnpm husky check --staged --fix", + "biome:format-all": "pnpm biome format --write"
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
package.json
(1 hunks)
🔇 Additional comments (1)
package.json (1)
10-10
: Verify the impact of global formatting
The new biome:fix
script will format all files in the project, which could potentially cause significant changes across the codebase.
Let's check the scope of files that would be affected:
✅ Verification successful
Biome formatting is safely configured for this project
The formatting changes are well-controlled for the following reasons:
- The project already uses Biome for formatting through
lint-staged
, which means the team has accepted Biome's formatting rules - The
biome:fix
script complements the existingbiome:fix-staged
script - There's no competing formatter (no Prettier or ESLint config found)
- The formatting is handled through a proper dependency (@biomejs/biome v1.9.4)
While this will affect many files (292 JS/TS/JSON files found), it's a safe addition since it's consistent with the project's existing formatting setup.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check which files would be affected by Biome formatting
# Find all files that Biome typically formats (JavaScript, TypeScript, JSON, etc.)
fd -e js -e jsx -e ts -e tsx -e json -e jsonc | wc -l
# Check if there's a Biome configuration file that might restrict the scope
fd -g 'biome.json' -g '.biomerc.json' -g 'biome.config.json'
Length of output: 281
Script:
#!/bin/bash
# Let's check if there's a Biome configuration file and its content
# Note: Fixing the previous fd command syntax
fd 'biome\.json$'
# Let's also check the content of package.json to understand the project structure
cat package.json
# Check if there are any existing formatting configurations
fd '\.prettierrc|\.eslintrc|\.editorconfig'
Length of output: 855
Dashboard now looks like:
Hva er endret?
Dokumentasjon / Storybook / testdekning
stories
iStorybook
, eller så er ikke dette relevant.Skjermbilder eller GIFs (valgfritt)
Summary by CodeRabbit
Release Notes
New Features
homepage
service, replacing the previousdave
service.bookmarks.yaml
,docker.yaml
,kubernetes.yaml
,services.yaml
,settings.yaml
, andwidgets.yaml
.homarr-config.json
to provide a comprehensive structure for dashboard applications and settings.Improvements
SearchBar
component for better responsiveness to search parameter changes.Chores
package.json
for formatting improvements.