Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 1 addition & 15 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,6 @@
"private": true,
"version": "0.0.0",
"type": "module",

"scripts": {
"dev": "vite --host",
"build": "vite build",
Expand All @@ -14,7 +13,6 @@
"docker:dev": "docker compose --profile dev up --build",
"docker:prod": "docker compose --profile prod up -d --build"
},

"dependencies": {
"@emotion/react": "^11.11.3",
"@emotion/styled": "^11.11.0",
Expand All @@ -37,7 +35,6 @@
"recharts": "^3.8.1",
"tailwindcss": "^3.4.14"
},

"devDependencies": {
"@eslint/js": "^9.13.0",
"@testing-library/jest-dom": "^6.9.1",
Expand All @@ -49,34 +46,23 @@
"@types/react-dom": "^18.3.7",
"@types/react-redux": "^7.1.34",
"@types/react-router-dom": "^5.3.3",

"@vitejs/plugin-react-swc": "^3.5.0",

"autoprefixer": "^10.4.20",
"bcryptjs": "^3.0.3",

"eslint": "^9.13.0",
"eslint-plugin-react": "^7.37.2",
"eslint-plugin-react-hooks": "^5.0.0",
"eslint-plugin-react-refresh": "^0.4.14",

"express-session": "^1.18.2",

"globals": "^15.11.0",

"jasmine": "^5.13.0",
"jasmine-spec-reporter": "^7.0.0",

"jsdom": "^29.1.1",

"passport": "^0.7.0",
"passport-local": "^1.0.0",

"supertest": "^7.2.2",

"typescript-eslint": "^8.59.3",

"vite": "^5.4.10",
"vite": "^8.0.14",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🌐 Web query:

Does Vite version 8.0.14 exist and what is the latest stable Vite version?

💡 Result:

Yes. Vite version 8.0.14 exists (it’s published as vite@8.0.14, with a May 21, 2026 release date) [1][2][3]. Latest stable Vite version (as of 2026-05-25): 8.0.14 [4][5][6].

Citations:


🌐 Web query:

What are the breaking changes between Vite 5 and Vite 8?

💡 Result:

Key breaking changes from Vite 5 → Vite 8 (selected, source-backed items): 1) Vite 7: Node.js requirement bump (and default ESM-only compatibility) Vite 7 requires Node.js 20.19+ and 22.12+ (dropping Node 18). This is a practical breaking change for dev/build environments. [1] 2) Vite 7: Default browser target changed to “baseline-widely-available” In Vite 7, the default build.target changes from 'modules' to 'baseline-widely-available', with updated baseline browser versions. If you rely on the old default target, output and transpilation may change. [1] 3) Vite 7: Several SSR-breaking removals/behavior changes The Vite 7 changelog calls out breaking SSR-related changes such as: removing access to Object in SSR transformed code, removing experimental.skipSsrTransform, and removing HotBroadcaster, among others. [2] 4) Vite 5: Node 18 minimum / CJS Node API deprecation / API cleanup work Vite 5 requires Node.js 18+ and deprecates the CJS Node API. It also documents multiple migration items around reworking define and import.meta.env.* replacement strategy, worker.plugins becoming a function, removal of --https / https: true, and removal of resolvePackageEntry / resolvePackageData. [3] 5) Vite 8 (March 12, 2026): Rolldown replaces the dual bundler setup Vite 8 is the major architectural change where Vite moves to Rolldown as a single unified Rust-based bundler (instead of the previous esbuild+Rollup split). This affects bundling/optimization behavior even if many configs/plugins are auto-converted. [4] 6) Vite 8: Node.js requirement bump (same as Vite 7) The Vite 8 announcement states Vite 8 requires Node.js 20.19+, 22.12+ (same ranges as Vite 7). [4] 7) Vite 8: Additional explicit breaking changes in the 8.0.0 changelog The Vite 8.0.0 changelog lists breaking changes including: - removing import.meta.hot.accept resolution fallback - updating the default browser target - the “rolldown-vite” merge [5] 8) If you maintain Rollup/Vite plugin-tooling: Vite 8/rolldown-vite incompatibilities for specific hook/options The Vite migration guide (covering the Rolldown migration in this line of releases) explicitly states Rolldown does not support certain Rollup-like outputs and Vite hooks anymore, e.g. build.rollupOptions.output.format: 'system' and 'amd', plus missing support for hooks like shouldTransformCachedModule, resolveImportMeta, renderDynamicImport, and resolveFileUrl. [6] 9) Vite 8 migration path recommendation: use rolldown-vite first (on Vite 7) For larger projects, Vite recommends a gradual approach: first switch to the rolldown-vite package on Vite 7 to isolate Rolldown-specific issues, then upgrade to Vite 8. [4] Where to look for the full list - Vite 8 migration guide + detailed changes are linked from the official Vite 8 announcement and the Vite migration guide. [4][7] - The authoritative breaking list is in the Vite changelog for the relevant majors (V5, V7, V8). [3][2][5] If you tell me your current versions (e.g., Vite 5.x + framework + Node version) and whether you use any low-level Rollup/Vite hooks, I can narrow this to the most likely breakpoints in your setup.

Citations:


🌐 Web query:

Is @vitejs/plugin-react version 4.3.3 compatible with Vite 8?

💡 Result:

Short answer: You should assume @vitejs/plugin-react@4.3.3 is not officially compatible with Vite 8. Why (grounded in sources): - The plugin repo/release notes state that Vite 8 compatibility was added by updating the plugin’s peerDependency range (“Add Vite 8 to peerDependencies”) and explicitly says “This plugin is compatible with Vite 8.” That change is not guaranteed to have been present in version 4.3.3. - npm’s package metadata shows @vitejs/plugin-react has a peer dependency on Vite “^8.0.0”, which indicates compatibility only for plugin versions where that peer range is in effect. Recommendation: upgrade @vitejs/plugin-react to a later version (one that includes the “Vite 8” peerDependencies update) when using Vite 8.

Citations:


🌐 Web query:

Is vitest version 4.1.6 compatible with Vite 8?

💡 Result:

Yes—Vitest 4.1.6 is compatible with Vite 8. Vitest 4.1 (the line that includes 4.1.6) explicitly added support for Vite 8 [1]. Additionally, Vitest’s migration guide states Vitest 4.0 requires Vite >= 6.0.0, which includes Vite 8 [2]. Finally, the Vitest v4.1.6 release notes/releases activity show this exact version (4.1.6) is part of that Vite 8-capable 4.1 branch [3][4]. Note: some early Vite 8 beta quirks were addressed in Vitest (Vitest removed “vite 8.beta” support), but that’s about the beta period, not Vite 8 stable [5].

Citations:


Vite 8 upgrade needs Node + plugin compatibility follow-up

  • vite@^8.0.14 exists, but the Vite 5 → 8 jump includes breaking changes (notably Node.js requirement bumps to ~20.19+/22.12+ and the Rolldown bundler transition), which can break dev/build/test unless your environment/config are updated.
  • vitest@^4.1.6 is compatible with Vite 8, but @vitejs/plugin-react@^4.3.3 is not guaranteed to support Vite 8—bump to a version that explicitly declares Vite 8 compatibility.
  • Also confirm @vitejs/plugin-react-swc works with Vite 8 (peerDependency/support may require an upgrade).
🤖 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 `@package.json` at line 65, The package.json bump to "vite": "^8.0.14" requires
follow-up: ensure Node engine and build tooling are upgraded (Node
~20.19+/22.12+), and upgrade plugin deps that list Vite 8 support — specifically
update `@vitejs/plugin-react` to a release that declares Vite 8 compatibility and
verify or bump `@vitejs/plugin-react-swc`; keep vitest@^4.1.6 (compatible) but run
dev/build/test locally and in CI to catch Rollup/Vite 8 bundler issues, and
update any config adapters or rollup plugins that report peerDependency
conflicts after changing vite, `@vitejs/plugin-react`, and
`@vitejs/plugin-react-swc` in package.json.

"vitest": "^4.1.6"
}
}
18 changes: 12 additions & 6 deletions src/pages/Contact/Contact.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -203,7 +203,13 @@ function Contact() {
Send us a Message
</h2>

<div className="space-y-3 sm:space-y-4 flex-1 flex flex-col">
<form
className="space-y-3 sm:space-y-4 flex-1 flex flex-col"
onSubmit={(e) => {
e.preventDefault();
handleSubmit();
}}
>
Comment on lines +206 to +212
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Form submission doesn't collect or send input data.

The form's onSubmit handler prevents default submission and calls handleSubmit(), but handleSubmit() (lines 19-32) only simulates a delay and shows a success popup—it never reads the form values. The inputs lack name attributes and aren't controlled (no value/onChange), so the user's name, email, subject, and message are never captured or sent anywhere.

📋 Proposed fix to collect form data
-            <form
-  className="space-y-3 sm:space-y-4 flex-1 flex flex-col"
-  onSubmit={(e) => {
-    e.preventDefault();
-    handleSubmit();
-  }}
->
+            <form
+  className="space-y-3 sm:space-y-4 flex-1 flex flex-col"
+  onSubmit={(e) => {
+    e.preventDefault();
+    const formData = new FormData(e.currentTarget);
+    const data = {
+      name: formData.get('name'),
+      email: formData.get('email'),
+      subject: formData.get('subject'),
+      message: formData.get('message'),
+    };
+    handleSubmit(data);
+  }}
+>

Then add name attributes to each input:

  • Line 225: <input type="text" name="name" ...
  • Line 248: <input type="email" name="email" ...
  • Line 271: <select name="subject" ...
  • Line 301: <textarea name="message" ...

And update handleSubmit signature to accept and use the data:

-  const handleSubmit = async () => {
+  const handleSubmit = async (data?: {name: string; email: string; subject: string; message: string}) => {
     setIsSubmitting(true);
 
-    // Simulate API call
+    // TODO: Send data to backend API
+    console.log('Form data:', data);
     await new Promise((resolve) => setTimeout(resolve, 1500));
🤖 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/pages/Contact/Contact.tsx` around lines 206 - 212, The form currently
prevents default and calls handleSubmit() but never collects user input; add
name attributes to the four fields (the name text input, email input, subject
select, and message textarea) and then update handleSubmit to actually read and
send the values—either by making the fields controlled with useState (create
state vars and wire value/onChange for inputs and use those in handleSubmit) or
by changing handleSubmit to accept the submit event and use new
FormData(e.currentTarget) to extract name,email,subject,message and then perform
the existing async/send logic and success popup; ensure you update the form
onSubmit to forward the event or data to handleSubmit accordingly.

<div className="space-y-3 flex-1">
{/* Full Name */}
<div>
Expand Down Expand Up @@ -303,24 +309,24 @@ function Contact() {
}`}
></textarea>

<button
onClick={handleSubmit}
<button
type="submit"
disabled={isSubmitting}
className={`absolute bottom-2 sm:bottom-3 right-2 sm:right-3 flex items-center gap-1.5 sm:gap-2 rounded-full px-3 sm:px-4 py-1.5 sm:py-2 text-xs sm:text-sm font-semibold transition-all duration-300 hover:scale-105 focus:outline-none focus:ring-2 focus:ring-purple-500 ${
isSubmitting
? "bg-purple-400 cursor-wait text-white"
: "bg-purple-600 hover:bg-purple-700 text-white"
}`}
>
>
{isSubmitting ? "Sending..." : "Send"}
<Send className="w-4 h-4" />
</button>
</div>
Comment on lines +312 to 324
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Consider accessibility implications of absolutely positioned button.

The submit button is absolutely positioned inside the textarea's container, overlaying the bottom-right corner of the text input area. While this creates a modern chat-like interface, it can cause usability issues:

  • Users typing longer messages may have text obscured by the button
  • Users with larger font sizes or zoom may find the button covers more of their input
  • The 4-row textarea height (line 304) is fixed, so long messages will scroll, but the button always covers the same corner

Unlike the Login and Signup forms in the codebase (see context snippets), which place the submit button outside and below the form inputs, this pattern reduces the effective usable area of the textarea.

Consider moving the button below the textarea or ensuring adequate padding/margin so text is never hidden.

♿ Proposed fix to move button outside textarea
                  <textarea
                    placeholder="Type your message here..."
                    required
                    rows={4}
                    className={`w-full p-2 sm:p-3 rounded-lg sm:rounded-xl text-sm sm:text-base resize-none transition-all duration-300 focus:outline-none focus:ring-2 focus:ring-purple-500 ${
                      mode === "dark"
                        ? "bg-white/5 border border-white/20 text-white placeholder-gray-400"
                        : "bg-gray-50 border border-gray-300 text-gray-800 placeholder-gray-500"
                    }`}
                  ></textarea>
+                </div>
 
-                 <button
+                <button
                    type="submit"
                    disabled={isSubmitting}
-                    className={`absolute bottom-2 sm:bottom-3 right-2 sm:right-3 flex items-center gap-1.5 sm:gap-2 rounded-full px-3 sm:px-4 py-1.5 sm:py-2 text-xs sm:text-sm font-semibold transition-all duration-300 hover:scale-105 focus:outline-none focus:ring-2 focus:ring-purple-500 ${
+                    className={`w-full sm:w-auto sm:ml-auto flex items-center justify-center gap-1.5 sm:gap-2 rounded-full px-4 sm:px-6 py-2 sm:py-3 text-sm font-semibold transition-all duration-300 hover:scale-105 focus:outline-none focus:ring-2 focus:ring-purple-500 ${
                      isSubmitting
                        ? "bg-purple-400 cursor-wait text-white"
                        : "bg-purple-600 hover:bg-purple-700 text-white"
                    }`}
-                        >
+                >
                    {isSubmitting ? "Sending..." : "Send"}
                    <Send className="w-4 h-4" />
                  </button>
-                </div>
🤖 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/pages/Contact/Contact.tsx` around lines 312 - 324, The submit button is
absolutely positioned inside the textarea container (the <button> with props
type="submit", disabled={isSubmitting} and child <Send />) which can obscure
typed text; fix by moving that button out of the textarea wrapper so it renders
as a sibling below the <textarea> (or alternatively remove absolute positioning
and add sufficient bottom padding to the textarea's container and adjust
tabindex/flow so the button follows normal DOM order), ensure styles for the
moved button preserve existing visual variants that use isSubmitting and the
same class names, and verify keyboard/focus order and visible focus ring remain
correct after relocation.

</div>
</div>
</form>
</div>
</div>
</div>
</div>

{/* Success Popup */}
{showPopup && (
Expand Down
Loading