Fix TypeScript build errors and prepare deployment#23
Conversation
📝 WalkthroughWalkthroughThis PR updates project configuration, TypeScript build tooling, and API type definitions while adapting authentication pages to a new ChangesProject Configuration and API Updates
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@next-env.d.ts`:
- Line 3: The file next-env.d.ts contains a manual import import
"./.next/types/routes.d.ts" that conflicts with the “do not edit” rule; either
enable typed routes in your Next config (set typedRoutes: true in
next.config.mjs) and re-run Next/typegen to regenerate next-env.d.ts and
.next/types/routes.d.ts, or remove the manual import line from next-env.d.ts so
the generated types reflect the current config; update next.config.mjs and
regenerate (or revert the import) to restore correct automated type generation.
In `@src/app/auth/set-password/page.tsx`:
- Around line 41-45: The setPassword call is sending a hardcoded empty username
("") which can fail backend validation; replace the empty string with the real
username value (e.g., the username/email from component props/state or from
URL/searchParams) or omit the username property entirely if the API derives it
from the otp/token; update the call to setPassword({ username: <actualUsername>,
otp: token, password }) (or remove username) and ensure the source used
(searchParams, form state, or a parent prop) is populated before invoking
setPassword.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 32fd5fd0-45ab-4c08-9270-d0b3d5630d64
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (6)
.idea/.gitignorenext-env.d.tssrc/app/auth/set-password/page.tsxsrc/app/auth/verify-otp/page.tsxsrc/types/api.tstsconfig.json
| /// <reference types="next" /> | ||
| /// <reference types="next/image-types/global" /> | ||
| /// <reference path="./.next/types/routes.d.ts" /> | ||
| import "./.next/types/routes.d.ts"; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Next.js 15 typed routes configuration next-env.d.ts correct syntax
💡 Result:
In Next.js 15, you should not manually edit the next-env.d.ts file [1][2][3]. This file is automatically generated and managed by Next.js whenever you run next dev, next build, or next typegen [1][2]. Modifying it will result in your changes being overwritten [1][2]. To enable and configure typed routes, follow these steps: 1. Enable typedRoutes: Open your next.config.js (or next.config.ts) and set typedRoutes to true [4]. // next.config.ts import type { NextConfig } from 'next'; const nextConfig: NextConfig = { typedRoutes: true, }; export default nextConfig; 2. Ensure tsconfig.json configuration: Your tsconfig.json must include the generated type definitions [1][2]. This is usually handled automatically by create-next-app, but you should verify that your include array contains the following paths [1][2]: { "include": [ "next-env.d.ts", ".next/types//.ts", "/.ts", "/.tsx" ] } 3. Custom Type Declarations: If you need to add your own custom type declarations, do not add them to next-env.d.ts [1][2]. Instead, create a separate file (e.g., custom-types.d.ts) and add that filename to the include array in your tsconfig.json [1][2][3]. How it works: When typedRoutes is enabled, Next.js generates a hidden directory at.next/types that contains information about all valid routes in your application [1][2]. By including.next/types//.ts in your tsconfig.json, the TypeScript compiler can access these generated types to provide real-time validation and autocompletion for href values in components like next/link and methods in next/navigation [1][2]. Important notes: - Version Control: It is recommended to add next-env.d.ts to your.gitignore file, as it is generated dynamically [1][2][3]. - CI/CD: If you perform separate type checking in your CI pipeline, ensure you run next typegen before your type checker (e.g., tsc --noEmit) to ensure the route types are up to date [5].
Citations:
- 1: https://nextjs.org/docs/app/api-reference/config/typescript
- 2: https://vercel-next-js.mintlify.app/api-reference/config/typescript
- 3: https://stackoverflow.com/questions/61420392/how-do-i-use-the-next-env-d-ts-file-in-next-js
- 4: https://nextjs.im/docs/15/app/api-reference/config/next-config-js/typedroutes/
- 5: Docs: Mention that
next typegenneeds to be run in CI in case of seperate type check vercel/next.js#82916
🏁 Script executed:
#!/bin/bash
# Check if next-env.d.ts is generated by Next.js commands
echo "Searching for Next.js type generation references..."
rg -n "next-env\.d\.ts" --type-add 'config:*.{json,js,mjs,ts}' --type config -C2
# Check package.json scripts that might regenerate types
cat package.json | jq -r '.scripts | to_entries[] | select(.value | contains("next")) | "\(.key): \(.value)"'Repository: SheCanCODE-Capstone-Projects/Med-Delivery-System-FE
Length of output: 666
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== next-env.d.ts (repo contents) ==="
if [ -f next-env.d.ts ]; then nl -ba next-env.d.ts | sed -n '1,120p'; else echo "next-env.d.ts not found at repo root"; fi
echo
echo "=== Search for typedRoutes config ==="
rg -n --hidden --glob 'next.config.*' "typedRoutes" . || true
rg -n --hidden "typedRoutes" . || true
echo
echo "=== Search for manual edits/mentions of .next/types/routes.d.ts ==="
rg -n --hidden "routes\.d\.ts" . || true
rg -n --hidden "next-env\.d\.ts" . || true
echo
echo "=== .gitignore entries for next-env.d.ts ==="
if [ -f .gitignore ]; then rg -n "next-env\.d\.ts" .gitignore || true; fiRepository: SheCanCODE-Capstone-Projects/Med-Delivery-System-FE
Length of output: 194
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== next-env.d.ts (repo contents) ==="
if [ -f next-env.d.ts ]; then
echo "found next-env.d.ts"
cat -n next-env.d.ts | sed -n '1,160p'
else
echo "next-env.d.ts not found at repo root"
fi
echo
echo "=== Search for typedRoutes config ==="
rg -n --hidden --glob 'next.config.*' "typedRoutes" . || true
rg -n --hidden "typedRoutes" . || true
echo
echo "=== Search for manual edits/mentions of .next/types/routes.d.ts ==="
rg -n --hidden "routes\.d\.ts" . || true
rg -n --hidden "next-env\.d\.ts" . || true
echo
echo "=== .gitignore entries for next-env.d.ts ==="
if [ -f .gitignore ]; then rg -n "next-env\.d\.ts" .gitignore || true; else echo "no .gitignore"; fiRepository: SheCanCODE-Capstone-Projects/Med-Delivery-System-FE
Length of output: 780
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== next.config.* files ==="
fd -a -t f -g 'next.config.*' . || true
echo
for f in $(fd -a -t f -g 'next.config.*' .); do
echo "=== $f (first 200 lines) ==="
sed -n '1,200p' "$f"
echo
done
echo "=== Look for typedRoutes mention anywhere ==="
rg -n --hidden "typedRoutes" . || true
echo "=== Does repo contain .next/types/routes.d.ts (usually not committed)? ==="
if [ -f .next/types/routes.d.ts ]; then
echo "found .next/types/routes.d.ts"
sed -n '1,120p' .next/types/routes.d.ts
else
echo ".next/types/routes.d.ts not present in repo working tree"
fiRepository: SheCanCODE-Capstone-Projects/Med-Delivery-System-FE
Length of output: 961
🌐 Web query:
next-env.d.ts import "./.next/types/routes.d.ts"; Next.js typed routes next-env.d.ts should not be edited syntax
💡 Result:
The file next-env.d.ts is an auto-generated file in Next.js projects that ensures TypeScript recognizes Next.js type definitions, such as those for non-code imports (e.g., images, stylesheets) and route types [1][2]. You should never manually edit this file [3][2]. Because it is automatically regenerated by Next.js commands like next dev, next build, and next typegen, any manual changes will be overwritten [2]. Key takeaways regarding next-env.d.ts: 1. Do not edit or remove it: The file is managed entirely by the Next.js framework [3][2]. 2. Version control: It is recommended to add next-env.d.ts to your.gitignore file to avoid unnecessary churn in version control, as the file content can change based on the last command run (e.g., dev vs. build) [4][2][5]. 3. Generation in CI: If your CI pipeline requires type checking (e.g., via tsc), you must ensure the file exists. You can generate it by running npx next typegen before your type-checking command [4][6][5]. 4. Custom types: If you need to add custom TypeScript declarations, create a separate.d.ts file and include it in your tsconfig.json file, rather than attempting to modify next-env.d.ts [3][1][2]. The import statement import "./.next/types/routes.d.ts"; is a standard part of this auto-generated file when the experimental typedRoutes feature is enabled [1][2]. It allows Next.js to provide type-safe hrefs for components like next/link [2].
Citations:
- 1: https://vercel-next-js.mintlify.app/api-reference/config/typescript
- 2: https://nextjs.org/docs/app/api-reference/config/typescript
- 3: https://stackoverflow.com/questions/61420392/how-do-i-use-the-next-env-d-ts-file-in-next-js
- 4: Docs: No longer any reference to next-env.d.ts in documentation vercel/next.js#58877
- 5: How to generate `next-env.d.ts` in a CI job that requires it? vercel/next.js#47010
- 6: Docs: Mention that
next typegenneeds to be run in CI in case of seperate type check vercel/next.js#82916
Stop manually editing next-env.d.ts; configure typed routes via next.config.mjs and let Next regenerate it.
next-env.d.ts is annotated as “This file should not be edited” but it now includes import "./.next/types/routes.d.ts";. Since next.config.mjs does not enable typedRoutes, this routes import likely came from a previous typegen run—update typed routes configuration (typedRoutes: true) and regenerate, or revert/remove the manual routes.d.ts import so type generation matches the current config.
🤖 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 `@next-env.d.ts` at line 3, The file next-env.d.ts contains a manual import
import "./.next/types/routes.d.ts" that conflicts with the “do not edit” rule;
either enable typed routes in your Next config (set typedRoutes: true in
next.config.mjs) and re-run Next/typegen to regenerate next-env.d.ts and
.next/types/routes.d.ts, or remove the manual import line from next-env.d.ts so
the generated types reflect the current config; update next.config.mjs and
regenerate (or revert the import) to restore correct automated type generation.
| const auth =await setPassword({ | ||
| username: "", | ||
| otp: token, | ||
| password | ||
| }); |
There was a problem hiding this comment.
Do not send an empty username in the set-password request.
At Line 42, username is hardcoded to "". Since setPassword forwards this payload directly, this can fail backend validation and block activation.
Proposed fix
const searchParams = useSearchParams();
const token = searchParams.get("token") ?? "";
+ const username = searchParams.get("username") ?? "";
@@
- if (!token) {
- setError("Invalid or missing activation token. Please use the link from your email.");
+ if (!token || !username) {
+ setError("Invalid activation link. Please use the latest link from your email.");
return;
}
@@
const auth =await setPassword({
- username: "",
+ username,
otp: token,
password
});📝 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.
| const auth =await setPassword({ | |
| username: "", | |
| otp: token, | |
| password | |
| }); | |
| const searchParams = useSearchParams(); | |
| const token = searchParams.get("token") ?? ""; | |
| const username = searchParams.get("username") ?? ""; | |
| if (!token || !username) { | |
| setError("Invalid activation link. Please use the latest link from your email."); | |
| return; | |
| } | |
| const auth =await setPassword({ | |
| username, | |
| otp: token, | |
| password | |
| }); |
🤖 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/auth/set-password/page.tsx` around lines 41 - 45, The setPassword
call is sending a hardcoded empty username ("") which can fail backend
validation; replace the empty string with the real username value (e.g., the
username/email from component props/state or from URL/searchParams) or omit the
username property entirely if the API derives it from the otp/token; update the
call to setPassword({ username: <actualUsername>, otp: token, password }) (or
remove username) and ensure the source used (searchParams, form state, or a
parent prop) is populated before invoking setPassword.
1 participant
Fixed multiple TypeScript build errors blocking the Next.js production build and Railway deployment.
Changes made:
Updated
SetPasswordRequesthandling to align request payloads across authentication pages.Fixed mismatched properties in password setup and OTP verification flows.
Corrected
setPassword()request payload usage in:src/app/auth/set-password/page.tsxsrc/app/auth/verify-otp/page.tsxAdded missing
patientNameproperty toPaymentResponseinterface insrc/types/api.ts.Resolved TypeScript type-checking issues preventing successful
npm run build.Verified successful production build generation for deployment.
Adjusted local start configuration compatibility issues related to
$PORThandling on Windows.Summary by CodeRabbit
New Features
Chores