feat: change auth page color scheme to blue-based#66
feat: change auth page color scheme to blue-based#66devin-ai-integration[bot] wants to merge 1 commit into
Conversation
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
| import { z } from "zod"; | ||
|
|
||
| import { SAMLLogin } from "@calcom/features/auth/SAMLLogin"; | ||
| import process from "node:process"; |
There was a problem hiding this comment.
🔴 Importing node:process in a "use client" component may break the login page in the browser
The PR adds import process from "node:process" at line 3 of apps/web/modules/auth/login-view.tsx, which is a "use client" component (line 1). The node: protocol prefix is meant for Node.js built-in modules and is not available in browser environments.
Root Cause
Before this PR, the code already referenced process.env.NEXT_PUBLIC_DISABLE_SIGNUP at line 186, but that worked fine because Next.js automatically inlines NEXT_PUBLIC_* environment variables as literal string values at build time — no actual process object is needed at runtime in the browser.
By explicitly importing process from "node:process", the bundler is now asked to resolve and include the Node.js process built-in module in the client-side bundle. Depending on how webpack/turbopack handles the node: protocol prefix for client bundles, this could cause:
- A build-time error (module not found)
- A runtime error in the browser (missing module)
The only other usage of import process from "node:process" in the codebase is in apps/web/app/e2e/session-warmup/page.tsx, which is a server component (no "use client" directive), so that usage is correct.
Impact: If the bundler fails to resolve node:process for the client bundle, the entire login page would be broken — users would be unable to log in.
| import process from "node:process"; |
Was this helpful? React with 👍 or 👎 to provide feedback.
What does this PR do?
Updates the auth pages (login, setup wizard) to use a blue-based color scheme instead of the default dark/gray theme.
Changes:
from-blue-50 to-blue-100), card border →border-blue-200, heading →text-blue-900#2563eb,#1e40af, etc.), sign-in button changed fromsecondarytoprimarybg-blue-600, inactive →bg-blue-200All changes include dark mode variants.
Link to Devin run: https://partner-workshops.devinenterprise.com/sessions/142d3dd0cb6147a5904057961845a69b
Visual Demo
Image Demo:
Login page (after):

Setup page (after):

Video Demo:
Setup wizard flow:
View original video (rec-e508b70556f544d0bc6c28bf8349244d-edited.mp4)
Login page local test:
View original video (rec-49740a7aee064d1cb945d977ae6155d7-edited.mp4)
Mandatory Tasks (DO NOT REMOVE)
How should this be tested?
yarn devand navigate tohttp://localhost:3000/auth/login(seeded DB) or/auth/setup?step=1(fresh DB)Human Review Checklist
Steps.tsxandWizardForm.tsxlive inpackages/ui/and are used across the entire app. The hardcoded blue colors will affect all wizard flows (onboarding, settings, etc.), not just auth pages. Confirm this is the intended scope — if not, these color changes should be scoped to auth-only wrappers.bg-inverted,text-emphasis,border-subtle) with hardcoded blue Tailwind classes. This breaks the design system's theming capabilities. Consider whether these should use CSS custom properties or design tokens for better maintainability and consistency.import process from "node:process"tologin-view.tsx(a"use client"component). Verify this doesn't cause issues in the client-side bundle —process.envis typically available in Next.js client components without explicit imports.dark:bg-blue-950,dark:text-blue-100, etc.) render correctly across both login and setup pages.Checklist