Skip to main content

Atria v0.4.0 Released - Full TypeScript Migration

· 4 min read
Aaliyah
Full-Stack Engineer

Hey everyone. I'm Aaliyah, the newest addition to the Atria team. For my first major contribution, I got to tackle something I've been wanting to do since I first looked at the codebase: migrate the entire frontend to TypeScript.

This post covers what changed, why it matters, and some lessons learned along the way.

By the Numbers

Let's start with the scope of this migration:

  • 768 files changed
  • 38,903 lines added
  • 26,179 lines removed
  • ~12,700 net new lines (mostly type definitions)

The frontend went from a JavaScript codebase with loose typing to strict TypeScript with allowJs: false and verbatimModuleSyntax enabled. No more implicit anys sneaking through.

What's New in v0.4.0

Added

Full TypeScript Migration

  • Complete frontend codebase converted from JavaScript to TypeScript (764 files)
  • Comprehensive type definitions for all API responses, Redux state, and component props
  • Strict type checking enabled across the board
  • Custom type definitions for drag-and-drop (dnd.ts) and Vimeo player (vimeo-player.d.ts)

Type Utilities

  • Generic utility types for common patterns (RequireKeys, Nullable, DeepPartial, etc.)
  • Type guards for runtime narrowing (isDefined, isNullish, isNonEmptyArray)
  • Branded types for type-safe IDs (can't accidentally pass a UserId where an EventId is expected)

Changed

  • All RTK Query API slices now have full type coverage
  • Socket.IO client fully typed with event payloads and callbacks
  • Enum values standardized to UPPERCASE across frontend and backend
  • Redux store, slices, and hooks converted with proper typing

Fixed

  • Type safety improvements eliminate entire categories of runtime errors
  • Consistent enum handling between frontend and backend
  • Modal Cancel buttons now use consistent custom Button styling
  • Backend privacy service normalizes stored enum values for legacy data

The Migration Journey

The Hard Part: Frontend-Backend Type Sync

The biggest headache was keeping types synchronized between the frontend and Python backend. When your API returns a user object, you need to make sure the frontend's User type actually matches what the backend sends.

We don't have automatic type generation from the OpenAPI spec yet (that's on the roadmap), so this was a manual process of auditing API responses and building matching TypeScript interfaces.

The Strategy: allowJs as a Bridge

For a codebase this size, a big-bang migration wasn't realistic. The approach:

  1. Enable allowJs to let TypeScript and JavaScript coexist
  2. Migrate files incrementally, using // TODO: comments and temporary any types where needed
  3. Once everything was converted, flip to allowJs: false and fix the remaining strict errors

This let us ship incremental progress without breaking the build.

The Fun Part: Generics

I got to use generics heavily throughout this migration, and honestly, that was the enjoyable part. Building reusable type utilities that make the rest of the codebase cleaner is satisfying work.

For example, our utility types let you do things like:

// Make specific keys required
type RequireKeys<T, K extends keyof T> = T & Required<Pick<T, K>>;

// Branded types for type-safe IDs
type UserId = Brand<number, 'UserId'>;
type EventId = Brand<number, 'EventId'>;

// Can't mix these up anymore
function getUser(id: UserId): User { ... }

Small things, but they add up to a codebase that catches mistakes at compile time instead of runtime.

Also in This Release

Jitsi Embed Fix

  • Fixed an issue with Jitsi video conferencing embeds
  • The demo account at atria.gg now has Jitsi enabled so you can test embedded conferencing

Migration Notes

For Existing Installations:

This release should be seamless. The TypeScript migration is entirely a frontend concern - no API changes, no database migrations, no new environment variables.

Just pull the latest code and rebuild. Your existing data and configuration will work exactly as before.

No breaking changes.

What's Next

With TypeScript in place, we have a much better foundation for:

  • Catching bugs earlier in development
  • Better IDE support and autocomplete
  • Easier refactoring with confidence
  • Eventually, auto-generated types from the OpenAPI spec

That's v0.4.0. If you run into any TypeScript-related issues, feel free to open an issue on GitHub. Happy holidays.