T3 Environment Package Introduction

• Framework-agnostic validation for typesafe environment variables
• Solves common problems with environment variables being hard to manage
• Originally built for create T3 app, now extracted for broader ecosystem use
• Created primarily by Julius with domain/support from presenter
• Package name: T3 EnV

Installation & Basic Setup

• Install: @t3-oss/env-core and optional @t3-oss/env-nextjs for Next.js
• Simple installation process via npm/pnpm
• Framework agnostic core with Next.js specific wrapper

Configuration Structure

• Create env file with client/server environment variable definitions
• Client prefix support (e.g., next_public for Next.js)
  • Specify client-only environment variables with required prefix
  • Everything else assumed to be server environment variables
• Uses Zod for validation schemas
• Import env from configured file for guaranteed validated variables

Next.js Specific Implementation

• Runtime env strict by default in Next.js package
• Must restructure all keys manually due to Next.js bundling behavior
• Only explicitly accessed variables included in bundler
• Requires additional runtime environment configuration
• Edge runtime limitations noted as potential bug to fix with Next.js team

Live Demo Setup

• Created new Next.js app with app directory
• Installed package via npm (presenter preferred pnpm but used npm)
• Configured env.mjs file with:
  • server_only: z.string().min(5) - minimum 5 characters
  • next_public_client_2: z.string().emoji() - must be emoji
• Next.js config must be .mjs format (TypeScript not yet supported)

Validation Testing

• Build fails immediately if environment variables missing/invalid
• Clear error messages for onboarding new developers
• Server-only variables validated at build time
• Client variables also validated with specific format requirements

Error Handling Examples

• "server_only string must contain at least 5 characters"
• "next_public_client is an invalid emoji"
• Immediate feedback before application runs
• Prevents runtime errors from invalid environment variables

Security Features

• Server components only run on server
• Environment variables can only leak through:
  • Direct return in markup
  • Props sent to client components
• Difficult to accidentally expose server variables to client

Final Implementation

• Successfully demonstrated working validation
• Server-only variable: "longer string" (5+ characters)
• Client variable: emoji character
• Build validation working correctly
• Runtime access working as expected