feat: add additional user info

[ilyaliao]

resolves #127

This PR exposes additional user information in the user route.

Summary by CodeRabbit

• New Features

  • The user profile retrieval endpoint now returns additional profile information including company affiliation, geographic location, personal blog URL, and email address alongside existing profile data.

• Documentation

  • API documentation updated with expanded examples showing all available user profile fields in endpoint responses.

[ilyaliao]

I’m not sure if I should update /users/find/{query}, since its response seems different.

[vercel]

@ilyaliao is attempting to deploy a commit to the Nitro Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

📝 Walkthrough

Walkthrough

Extended the user profile response across the API to include four additional GitHub profile fields—company, location, blog, and email—by updating the type definitions, route handler, and documentation examples.

Changes

Cohort / File(s)	Summary
Type Definitions & Documentation types/index.ts, README.md	Added company, location, blog, and email fields to the GithubUser interface and updated the example API response JSON in documentation.
API Handler routes/users/[name]/index.ts	Extended the user payload returned by the GET /users/{username} endpoint to include the four new GitHub profile fields alongside existing fields.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A burrow of fields, now expanded and bright!
More company, location, blog in sight,
Each email a thread in the web we have spun,
GitHub profiles richer, our mission more fun! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat: add additional user info' is concise and directly references the main change—adding extra user profile fields to the API response.
Linked Issues check	✅ Passed	The PR successfully implements all requested fields (company, location, blog, email) from issue #127 across the type definitions, route handler, and documentation.
Out of Scope Changes check	✅ Passed	All changes are narrowly scoped to adding the four requested user fields; no unrelated modifications are present.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@types/index.ts`:
- Around line 27-30: The GithubUser interface currently types company, location,
blog, and email as plain strings but the GitHub API may return null for these
fields; update the GithubUser definition so those properties are typed as string
| null (i.e., company: string | null; location: string | null; blog: string |
null; email: string | null) to match the API response and prevent type errors in
consumers of the GithubUser type.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4bcfb8d8-fdf8-41a7-be76-b4cf0643e41b

📥 Commits

Reviewing files that changed from the base of the PR and between 6293e16 and d04f86b.

📒 Files selected for processing (3)

• README.md
• routes/users/[name]/index.ts
• types/index.ts

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

In the GitHub REST API "Get a user" response schema, are company, location, blog, and email nullable (string | null)?

💡 Result:

Yes, in the GitHub REST API "Get a user" (GET /users/{username}) response schema, the fields company, location, blog, and email are all nullable (type: string or null). This is confirmed in the official GitHub documentation for the response schema of related endpoints like GET /user (which shares the same schema), explicitly listing: - company: required, string or null - location: required, string or null - blog: required, string or null - email: required, string or null, format: email Additionally, schema definitions from API documentation tools (e.g., public-user schema) specify these fields as type: string, nullable: true. Real-world examples and notes in docs state that email is null if no public email is set, and similar logic applies to the others when not provided in the user's profile.

Citations:

• 1: https://docs.github.com/en/rest/users?apiVersion=2022-11-28
• 2: https://docs.github.com/en/enterprise-server@3.5/rest/users/users
• 3: https://docs.github.com/en/rest/users/users
• 4: https://docs.github.com/en/rest/users/users?apiVersion=2022-11-28
• 5: https://github.apidog.io/api-3489590
• 6: https://docs.github.com/en/enterprise-cloud@latest/rest/users/users?apiVersion=2022-11-28

---

Make the new GithubUser profile fields nullable.

Lines 27-30 are typed as string, but these GitHub profile fields can be null in the API response. The GitHub REST API "Get a user" endpoint returns company, location, blog, and email as string | null.

Suggested fix

 export interface GithubUser {
   id: string;
   username: string;
   name: string;
   twitter: string;
   avatar: string;
-  company: string;
-  location: string;
-  blog: string;
-  email: string;
+  company: string | null;
+  location: string | null;
+  blog: string | null;
+  email: string | null;
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@types/index.ts` around lines 27 - 30, The GithubUser interface currently
types company, location, blog, and email as plain strings but the GitHub API may
return null for these fields; update the GithubUser definition so those
properties are typed as string | null (i.e., company: string | null; location:
string | null; blog: string | null; email: string | null) to match the API
response and prevent type errors in consumers of the GithubUser type.