Add GitHub organization search feature GitHub org search feature#60
Add GitHub organization search feature GitHub org search feature#60coderpurohit wants to merge 2 commits into
Conversation
WalkthroughThis PR implements a complete GitHub organization search feature. Users can search for organizations by name, the app fetches organization data from GitHub's API, and displays results in a styled card with metadata including avatar, description, followers, and public repositories. ChangesOrganization Search Application
Sequence Diagram(s)sequenceDiagram
participant User
participant SearchBar
participant App
participant fetchOrganization
participant GitHub API
participant OrgCard
User->>SearchBar: enter org name and submit
SearchBar->>App: onSearch(orgName)
App->>App: setLoading(true), clearError()
App->>fetchOrganization: fetchOrganization(orgName)
fetchOrganization->>GitHub API: GET /orgs/{orgName}
GitHub API-->>fetchOrganization: organization JSON
fetchOrganization-->>App: GitHubOrg data
App->>App: setOrganization(data), setLoading(false)
App->>OrgCard: render with organization data
OrgCard-->>User: display card with avatar, stats, link
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
github-actions
Bot
added
no-issue-linked
configuration
dependencies
frontend
javascript
size/L
first-time-contributor
and removed
size/L
labels
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
🤖 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/App.css`:
- Line 9: Stylelint is flagging extra empty lines before CSS declarations in
App.css (e.g., the rule containing "display: flex;" and other declarations at
the lines referenced); fix by removing the blank lines that precede each
declaration so declarations immediately follow their selector or previous
property, or run stylelint --fix to auto-correct; update the selectors/rules
that include "display: flex;" and the other noted declarations so they conform
to the project's Stylelint formatting rules.
In `@src/App.tsx`:
- Line 38: Hardcoded user-facing strings in the App component (the
<h1>OrgExplorer</h1>, the "Loading..." text and the error messages shown in
render) must be moved to i18n resource keys and referenced from code; replace
the literal strings in App (the h1 element and wherever loading/error messages
are rendered) with calls to your localization API (e.g.,
useTranslation()/t('...') or a getString('...') helper) using clear keys like
title.orgExplorer, loading.message, and error.fetchFailed, and add those keys
with appropriate values to the locale resource file(s); update any imports
(e.g., import { useTranslation } from 'react-i18next' or your project
equivalent) and ensure the component uses the translation function to render the
strings.
- Around line 28-30: The catch block swallows the thrown error; update it to
accept and use the error parameter (e.g., catch (err)) so you can log the full
error and provide a more informative message via setError and preserve state
with setOrganization(null); specifically, in the block that currently calls
setOrganization(null) and setError('Organization not found'), change it to
capture the error object, call console.error or a logger with err (or
err.message), and setError to include a clearer diagnostic (e.g., include
err.message or a mapped user-facing message) while still calling
setOrganization(null).
In `@src/components/orgcard.tsx`:
- Line 20: The hardcoded user-facing labels in the OrgCard component (e.g., the
JSX lines rendering "Followers:", "Public Repositories:" and "Visit GitHub
Profile") must be externalized for i18n; replace those literal strings in the
OrgCard (component/function name: OrgCard or OrganizationCard where it renders
organization.followers, organization.public_repos and the GitHub link) with
lookups to the localization resource (e.g., import a locale/strings object or
use the app's t() translator) and update the JSX to use those keys (followers,
publicRepositories, visitGitHubProfile), ensuring the organization props remain
unchanged.
- Around line 10-14: The img element rendering organization.avatar_url is
missing a height attribute which can cause layout shift; update the OrgCard
component (the JSX containing <img src={organization.avatar_url}
alt={organization.login} width={120} />) to include a matching height attribute
(or explicit aspect-ratio-preserving dimensions) so width and height are both
set (or computed from known avatar dimensions) to prevent CLS.
- Line 18: The organization description may be null/undefined and currently
renders literal "null"/"undefined"; update the OrgCard component in
src/components/orgcard.tsx to guard rendering of organization.description (the
organization object and its description property) and provide a fallback string
or omit the element—e.g., conditionally render the <p> only when
organization.description is truthy or render organization.description ?? 'No
description provided'—so the UI never shows "null" or "undefined".
In `@src/components/serachbar.tsx`:
- Line 25: The hardcoded user-facing strings in the SearchBar component
(placeholder="Enter GitHub organization" and the button label) must be
externalized for i18n; add a localization resource/constant (or use
react-i18next) and replace the literal placeholder and button text in the
serachbar.tsx component with references to those localized keys (e.g.,
t('search.placeholder') or LOCAL_STRINGS.SEARCH_PLACEHOLDER) and ensure the
component imports and uses the localization helper (hook or constants) so both
the input placeholder and the button label are driven from the resource file.
- Around line 1-35: The component file has a typo in its filename
("serachbar.tsx"); rename the file to "searchbar.tsx" so the module name matches
the exported component SearchBar, and update the import statement in App.tsx
that currently imports SearchBar to reference the corrected filename; ensure any
other imports/exports referencing "serachbar" are updated to "searchbar" to
avoid module resolution errors.
In `@src/main.tsx`:
- Around line 10-12: Remove the unused BrowserRouter wrapper around App: delete
the BrowserRouter element and its import from main.tsx so App is rendered
directly (remove any "BrowserRouter" import and JSX). Also remove the
react-router-dom dependency from the project manifest and lockfile (uninstall
react-router-dom with your package manager and update package.json/package-lock
or yarn.lock accordingly) to avoid unused dependency warnings.
In `@src/services/githubapi.ts`:
- Line 11: The hardcoded user-facing error string "Organization not found" must
be externalized for i18n: replace the inline throw new Error('Organization not
found') in src/services/githubapi.ts with a throw new Error(...) that uses your
localization/resource lookup (e.g., call the project's i18n translate function
or import the errors resource and use a key like errors.organizationNotFound);
ensure you import the localization helper at the top (e.g., i18n or t) and
reference the resource key instead of the literal string, and update any unit
tests or callers that assert on this exact message to use the localized key or
compare error codes where appropriate.
- Around line 10-12: Replace the generic error thrown when response.ok is false
with explicit handling of response.status in the fetch/org call: inspect
response.status from the code block that contains the `if (!response.ok)` check
and throw distinct errors/messages for 404 (throw "Organization not found"), 429
(throw "Rate limited by GitHub" and surface retry info/Retry-After header),
401/403 (throw "Authentication/permission error" with status), and 5xx (throw
"GitHub server error" including status); keep a fallback that includes status
and response text for any other unexpected codes so debugging has full context.
- Line 7: The orgName is interpolated directly into the GitHub API URL; update
the interpolation to pass orgName through encodeURIComponent to defensively
escape any unexpected characters (i.e., replace occurrences of
`https://api.github.com/orgs/${orgName}` with a version that uses
`encodeURIComponent(orgName)`), ensuring the URL-building code in
src/services/githubapi.ts uses the encoded orgName wherever that template string
or the orgName variable is used.
In `@src/types/github.ts`:
- Line 4: The GitHub organization type marks the description property as
non-nullable; update the declaration for the description field from string to
allow null (e.g., change the description property in the type/interface that
currently reads "description" to accept string | null) so the API contract
matches GitHub's "string or null" behavior and downstream consumers handle null
values correctly.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: da1499f7-b2ce-42c1-855c-cf8b0d15d4ef
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (9)
package.jsonsrc/App.csssrc/App.tsxsrc/components/orgcard.tsxsrc/components/serachbar.tsxsrc/index.csssrc/main.tsxsrc/services/githubapi.tssrc/types/github.ts
| min-height: 100vh; | ||
| min-height: 100dvh; | ||
|
|
||
| display: flex; |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Address Stylelint formatting warnings.
Stylelint is flagging empty lines before declarations throughout the file. While these are minor style issues, consider running stylelint --fix to auto-correct them for consistency with your project's linting rules.
Also applies to: 13-13, 15-15, 34-34, 37-37, 43-43, 46-46, 48-48, 55-55, 57-57, 59-59, 61-61
🧰 Tools
🪛 Stylelint (17.11.0)
[error] 9-9: Expected no empty line before declaration (declaration-empty-line-before)
(declaration-empty-line-before)
🤖 Prompt for 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.
In `@src/App.css` at line 9, Stylelint is flagging extra empty lines before CSS
declarations in App.css (e.g., the rule containing "display: flex;" and other
declarations at the lines referenced); fix by removing the blank lines that
precede each declaration so declarations immediately follow their selector or
previous property, or run stylelint --fix to auto-correct; update the
selectors/rules that include "display: flex;" and the other noted declarations
so they conform to the project's Stylelint formatting rules.
| } catch { | ||
| setOrganization(null) | ||
| setError('Organization not found') |
There was a problem hiding this comment.
Capture and handle the error for better diagnostics.
The catch block ignores the error parameter, losing valuable information about the failure (e.g., network error vs. 404 vs. rate limiting). This makes debugging difficult and provides a generic error message to users regardless of the actual problem.
🔍 Proposed fix
- } catch {
+ } catch (err) {
setOrganization(null)
- setError('Organization not found')
+ setError(
+ err instanceof Error
+ ? err.message
+ : 'Failed to fetch organization'
+ )
} finally {📝 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.
| } catch { | |
| setOrganization(null) | |
| setError('Organization not found') | |
| } catch (err) { | |
| setOrganization(null) | |
| setError( | |
| err instanceof Error | |
| ? err.message | |
| : 'Failed to fetch organization' | |
| ) | |
| } finally { |
🤖 Prompt for 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.
In `@src/App.tsx` around lines 28 - 30, The catch block swallows the thrown error;
update it to accept and use the error parameter (e.g., catch (err)) so you can
log the full error and provide a more informative message via setError and
preserve state with setOrganization(null); specifically, in the block that
currently calls setOrganization(null) and setError('Organization not found'),
change it to capture the error object, call console.error or a logger with err
(or err.message), and setError to include a clearer diagnostic (e.g., include
err.message or a mapped user-facing message) while still calling
setOrganization(null).
| <h1>Hello, OrgExplorer!</h1> | ||
| </> | ||
| <div className="app-container"> | ||
| <h1>OrgExplorer</h1> |
There was a problem hiding this comment.
Externalize user-facing strings for internationalization.
The title "OrgExplorer", loading message "Loading...", and error messages are hardcoded. As per coding guidelines, user-visible strings should be externalized to resource files for i18n support.
Also applies to: 42-42, 44-44
🤖 Prompt for 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.
In `@src/App.tsx` at line 38, Hardcoded user-facing strings in the App component
(the <h1>OrgExplorer</h1>, the "Loading..." text and the error messages shown in
render) must be moved to i18n resource keys and referenced from code; replace
the literal strings in App (the h1 element and wherever loading/error messages
are rendered) with calls to your localization API (e.g.,
useTranslation()/t('...') or a getString('...') helper) using clear keys like
title.orgExplorer, loading.message, and error.fetchFailed, and add those keys
with appropriate values to the locale resource file(s); update any imports
(e.g., import { useTranslation } from 'react-i18next' or your project
equivalent) and ensure the component uses the translation function to render the
strings.
| <img | ||
| src={organization.avatar_url} | ||
| alt={organization.login} | ||
| width={120} | ||
| /> |
There was a problem hiding this comment.
Add height attribute to prevent layout shift.
The <img> tag has a width but no height attribute, which can cause Cumulative Layout Shift (CLS) as the image loads. As per coding guidelines, code should follow best practices recommended by lighthouse for performance.
🎨 Proposed fix
<img
src={organization.avatar_url}
alt={organization.login}
width={120}
+ height={120}
/>🤖 Prompt for 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.
In `@src/components/orgcard.tsx` around lines 10 - 14, The img element rendering
organization.avatar_url is missing a height attribute which can cause layout
shift; update the OrgCard component (the JSX containing <img
src={organization.avatar_url} alt={organization.login} width={120} />) to
include a matching height attribute (or explicit aspect-ratio-preserving
dimensions) so width and height are both set (or computed from known avatar
dimensions) to prevent CLS.
|
|
||
| <h2>{organization.login}</h2> | ||
|
|
||
| <p>{organization.description}</p> |
There was a problem hiding this comment.
Add null/undefined handling for optional fields.
The description field may be null or undefined for some GitHub organizations, which would render "null" or "undefined" as text. Consider adding conditional rendering or a fallback.
🛡️ Proposed fix
- <p>{organization.description}</p>
+ <p>{organization.description || 'No description available'}</p>📝 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.
| <p>{organization.description}</p> | |
| <p>{organization.description || 'No description available'}</p> |
🤖 Prompt for 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.
In `@src/components/orgcard.tsx` at line 18, The organization description may be
null/undefined and currently renders literal "null"/"undefined"; update the
OrgCard component in src/components/orgcard.tsx to guard rendering of
organization.description (the organization object and its description property)
and provide a fallback string or omit the element—e.g., conditionally render the
<p> only when organization.description is truthy or render
organization.description ?? 'No description provided'—so the UI never shows
"null" or "undefined".
| <BrowserRouter> | ||
| <App /> | ||
| </BrowserRouter> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Search for Route components in the codebase
echo "Searching for Route usage..."
rg -n --type=tsx --type=ts -C3 '<Route'
echo -e "\nSearching for Routes component..."
rg -n --type=tsx --type=ts -C3 '<Routes'
echo -e "\nSearching for 404 or NotFound components..."
fd -e tsx -e ts -i '404|notfound'Repository: AOSSIE-Org/OrgExplorer
Length of output: 249
🏁 Script executed:
cat -n src/main.tsxRepository: AOSSIE-Org/OrgExplorer
Length of output: 486
🏁 Script executed:
# Better search for Route/Routes components without problematic file type flags
rg -n '<Route' --Repository: AOSSIE-Org/OrgExplorer
Length of output: 48
🏁 Script executed:
# Search in package.json for react-router-dom
cat package.json | grep -A 20 '"dependencies"'Repository: AOSSIE-Org/OrgExplorer
Length of output: 666
🏁 Script executed:
# Search for any routing configuration
rg -n 'Routes\|Route\|createBrowserRouter' --Repository: AOSSIE-Org/OrgExplorer
Length of output: 48
🏁 Script executed:
cat -n src/App.tsxRepository: AOSSIE-Org/OrgExplorer
Length of output: 1503
🏁 Script executed:
# Also search more broadly for any router setup
rg -n 'Router\|Route\|createBrowserRouter' --Repository: AOSSIE-Org/OrgExplorer
Length of output: 48
Remove unused BrowserRouter wrapper and react-router-dom dependency.
The BrowserRouter component is wrapping the App, but no <Routes>, <Route>, or routing implementation exists anywhere in the codebase. The application is a single-page search interface with no need for client-side routing. Remove the BrowserRouter wrapper from src/main.tsx and uninstall the react-router-dom dependency from package.json.
🤖 Prompt for 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.
In `@src/main.tsx` around lines 10 - 12, Remove the unused BrowserRouter wrapper
around App: delete the BrowserRouter element and its import from main.tsx so App
is rendered directly (remove any "BrowserRouter" import and JSX). Also remove
the react-router-dom dependency from the project manifest and lockfile
(uninstall react-router-dom with your package manager and update
package.json/package-lock or yarn.lock accordingly) to avoid unused dependency
warnings.
| orgName: string, | ||
| ): Promise<GitHubOrg> { | ||
| const response = await fetch( | ||
| `https://api.github.com/orgs/${orgName}`, |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In JavaScript, should dynamic URL path segments from user input be wrapped with encodeURIComponent before fetch requests?
💡 Result:
Yes—if a dynamic URL path segment is derived from user input, you should percent-encode that segment (commonly via encodeURIComponent) before inserting it into the path you pass to fetch. Why: - encodeURIComponent is explicitly intended for encoding “a URI component” (including “a path”); it “escapes a larger set of characters” and is recommended for “user-entered fields… passed as part of a URI” to avoid unexpected parsing/requests [1]. - The WHATWG URL Standard defines percent-encoding for URL path building and notes that using the same percent-encoding behavior corresponds to JavaScript’s encodeURIComponent [2]. - Security-wise, unencoded special characters (notably characters used for path traversal patterns) can change what the server thinks the path is; OWASP documents that traversal payloads rely on encoded forms like %2e%2e/%2f and discusses encoding/double-encoding effects [3]. How to apply: - Encode only the segment (not the whole URL). For example, when building /users//profile: - const idSegment = encodeURIComponent(userSuppliedId); - fetch(/users/${idSegment}/profile) Notes / pitfalls: - Don’t encode slashes as path separators. If your “segment” might contain '/', you generally must encode it so it stays inside the segment (encodeURIComponent will do that), otherwise it becomes an additional path segment. - Avoid double-encoding: if the user input is already percent-encoded, applying encodeURIComponent again will produce %25… sequences (encoding the percent sign).
Citations:
- 1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent
- 2: https://url.spec.whatwg.org/
- 3: https://owasp.org/www-community/attacks/Path_Traversal
🏁 Script executed:
cat -n src/services/githubapi.tsRepository: AOSSIE-Org/OrgExplorer
Length of output: 487
🏁 Script executed:
rg "fetchOrganization" --type ts --type tsx -B 3 -A 3Repository: AOSSIE-Org/OrgExplorer
Length of output: 94
🏁 Script executed:
rg "fetchOrganization" -B 3 -A 3Repository: AOSSIE-Org/OrgExplorer
Length of output: 898
🏁 Script executed:
cat -n src/App.tsxRepository: AOSSIE-Org/OrgExplorer
Length of output: 1503
🏁 Script executed:
find . -type f -name "*search*" -o -name "*Search*" | grep -v node_modulesRepository: AOSSIE-Org/OrgExplorer
Length of output: 48
🏁 Script executed:
ls -la src/components/Repository: AOSSIE-Org/OrgExplorer
Length of output: 297
🏁 Script executed:
cat -n src/components/serachbar.tsxRepository: AOSSIE-Org/OrgExplorer
Length of output: 976
🌐 Web query:
GitHub organization name constraints allowed characters rules
💡 Result:
GitHub organization names (also called logins) must consist only of alphanumeric characters (A-Z, a-z, 0-9) and hyphens (-).[1][2][3] They have a maximum length of 39 characters.[1] They cannot start with a hyphen,[1] cannot contain consecutive hyphens,[1] cannot be a reserved name,[1] and must be globally unique across GitHub.[1] Official GitHub documentation does not explicitly state these character rules, but they are confirmed by empirical testing of the creation process and real-world examples (e.g., organizations like VFDE-Mine).[1][2][3] Organization names are case-insensitive.[4]
Citations:
- 1: https://github.com/dead-claudia/github-limits
- 2: 'gh api graphql' fails for organization with hyphen in its name cli/cli#9949
- 3: ARC not working with an organization whose name ends in hyphen actions/actions-runner-controller#3663
- 4: https://docs.github.com/en/rest/orgs/orgs?apiVersion=2026-03-10
Encode the organization name before interpolating it into the URL.
Although GitHub organization names are restricted to alphanumeric characters and hyphens, orgName should still be passed through encodeURIComponent as a defensive best practice before placing it in the URL path. This prevents issues if the validation logic upstream changes.
Suggested change
const response = await fetch(
- `https://api.github.com/orgs/${orgName}`,
+ `https://api.github.com/orgs/${encodeURIComponent(orgName)}`,
)📝 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.
| `https://api.github.com/orgs/${orgName}`, | |
| const response = await fetch( | |
| `https://api.github.com/orgs/${encodeURIComponent(orgName)}`, | |
| ) |
🤖 Prompt for 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.
In `@src/services/githubapi.ts` at line 7, The orgName is interpolated directly
into the GitHub API URL; update the interpolation to pass orgName through
encodeURIComponent to defensively escape any unexpected characters (i.e.,
replace occurrences of `https://api.github.com/orgs/${orgName}` with a version
that uses `encodeURIComponent(orgName)`), ensuring the URL-building code in
src/services/githubapi.ts uses the encoded orgName wherever that template string
or the orgName variable is used.
| if (!response.ok) { | ||
| throw new Error('Organization not found') | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For GitHub REST API organization endpoint /orgs/{org}, which HTTP status codes are returned for not found, rate limit exceeded, and forbidden/auth-related failures?
💡 Result:
For GitHub REST API endpoint GET /orgs/{org} (organization endpoint): 1) Not found - 404 Not Found (resource not found) [1] 2) Rate limit exceeded - 403 Forbidden (rate limit exceeded) or 429 Too Many Requests (rate limit exceeded) [2][3] 3) Forbidden / auth-related failures - 401 Requires authentication [1] - 403 Forbidden (forbidden; includes insufficient scope / authz) [1][4] Notes on how GitHub signals auth vs existence: - GitHub may return 404 Not Found instead of 403 Forbidden in some authentication scenarios (to avoid confirming the existence of private resources). [5]
Citations:
- 1: https://docs.github.com/en/rest/orgs/orgs?apiVersion=2026-03-10
- 2: https://docs.github.com/en/rest/orgs/orgs?apiVersion=2022-11-28
- 3: https://docs.github.com/en/rest/orgs
- 4: https://docs.github.com/rest/orgs/orgs
- 5: https://gist.github.com/IaroslavR/cf3de7efe581fa483d9fa661cadebb14
🏁 Script executed:
# First, locate and read the githubapi.ts file
fd -t f -i githubapi.tsRepository: AOSSIE-Org/OrgExplorer
Length of output: 92
🏁 Script executed:
# Read the githubapi.ts file to inspect lines 10-12 and surrounding context
cat -n src/services/githubapi.ts | head -30Repository: AOSSIE-Org/OrgExplorer
Length of output: 487
Handle HTTP status codes explicitly instead of mapping all failures to "Organization not found".
The current code treats 404 (not found), 403 (forbidden), 429 (rate limit), 401 (authentication), and 5xx (server errors) identically, which provides incorrect user feedback and complicates debugging. Differentiate between status codes: 404 for missing organizations, 429 for rate limits, 403/401 for authentication issues, and 5xx for server failures.
🤖 Prompt for 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.
In `@src/services/githubapi.ts` around lines 10 - 12, Replace the generic error
thrown when response.ok is false with explicit handling of response.status in
the fetch/org call: inspect response.status from the code block that contains
the `if (!response.ok)` check and throw distinct errors/messages for 404 (throw
"Organization not found"), 429 (throw "Rate limited by GitHub" and surface retry
info/Retry-After header), 401/403 (throw "Authentication/permission error" with
status), and 5xx (throw "GitHub server error" including status); keep a fallback
that includes status and response text for any other unexpected codes so
debugging has full context.
| ) | ||
|
|
||
| if (!response.ok) { | ||
| throw new Error('Organization not found') |
There was a problem hiding this comment.
Externalize this user-facing error string for i18n.
On Line 11, the hardcoded message should come from localization resources instead of inline text.
As per coding guidelines "Internationalization: User-visible strings should be externalized to resource files (i18n)".
🤖 Prompt for 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.
In `@src/services/githubapi.ts` at line 11, The hardcoded user-facing error string
"Organization not found" must be externalized for i18n: replace the inline throw
new Error('Organization not found') in src/services/githubapi.ts with a throw
new Error(...) that uses your localization/resource lookup (e.g., call the
project's i18n translate function or import the errors resource and use a key
like errors.organizationNotFound); ensure you import the localization helper at
the top (e.g., i18n or t) and reference the resource key instead of the literal
string, and update any unit tests or callers that assert on this exact message
to use the localized key or compare error codes where appropriate.
| export interface GitHubOrg { | ||
| login: string | ||
| avatar_url: string | ||
| description: string |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In GitHub REST API docs for "Organizations - Get an organization", is the description field nullable in the response schema?
💡 Result:
Yes. In the GitHub REST API docs for “Organizations - Get an organization” (GET /orgs/{org}), the response schema lists description as “string or null” (i.e., it is nullable) [1].
Citations:
Fix description nullability in the API contract.
On Line 4, description is typed as string, but the GitHub REST API docs for "Get an organization" specify the field as "string or null". This mismatch can break consumers that assume non-null values.
Suggested change
export interface GitHubOrg {
login: string
avatar_url: string
- description: string
+ description: string | null
public_repos: number
followers: number
html_url: string
}📝 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.
| description: string | |
| export interface GitHubOrg { | |
| login: string | |
| avatar_url: string | |
| description: string | null | |
| public_repos: number | |
| followers: number | |
| html_url: string | |
| } |
🤖 Prompt for 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.
In `@src/types/github.ts` at line 4, The GitHub organization type marks the
description property as non-nullable; update the declaration for the description
field from string to allow null (e.g., change the description property in the
type/interface that currently reads "description" to accept string | null) so
the API contract matches GitHub's "string or null" behavior and downstream
consumers handle null values correctly.
1 participant
Implemented the GitHub organization search feature using the GitHub API.
Changes made:
Tested locally with multiple organizations and verified build/lint checks.
Summary by CodeRabbit
Release Notes
New Features
Dependencies