DEV Community

Cover image for How I migrated my pet project to TypeScript, or Katya in Wonderland
Ecaterina Sevciuc
Ecaterina Sevciuc

Posted on

How I migrated my pet project to TypeScript, or Katya in Wonderland

#devchallenge #wecoded #dei #career

WeCoded 2026: Echoes of Experience 💜

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I’ve finished my TypeScript course!.. But there's no need to congratulate me yet...

At first, I thought that after JS, nothing could surprise me anymore. When you read the textbook and look at the examples, you think: “Oh, everything's clear!”. But then you look at a blank file in VSCode and have no idea what to write: the textbook examples don’t seem to apply, and my imagination (or experience) is just not there. And on top of that: my logic seems to be acting up, too! 😂

In moments like these, you feel like Alice in Wonderland — the further you go, the “curiouser and curiouser” it gets. But at least Alice had a Caterpillar who helped her adapt to the situation — by offering mushrooms! 😂 But I have no caterpillar, and certainly no mushrooms.

❓ But in all seriousness:

  1. Why is TypeScript a separate topic from JavaScript? If the goal is reliable code, wouldn't it be more logical to start learning with a typed approach right away, so that all the "Alices" out there learn on safe examples from the start?
  2. If TypeScript is just a superset of JS, where is the boundary — should you learn "pure JS" first and then TS, or just take TS as your primary language?
  3. Which JS weaknesses actually hinder production, and does TS really solve them all?
  4. Do TS types actually help catch bugs earlier? And how much do they complicate fast, JS-style prototyping?

📁 About the project:

  • The migration goal: To increase code reliability, unify types between the frontend and backend, and simplify refactoring — that’s if we're putting it nicely and professionally.
  • But if we're being blunt: I just wanted to finally understand what TS is and "what you eat it with" (how it actually works) 😂

📁 What I migrated:

  • Frontend: UI and log display logic: 
export interface ErrorItem {
  id: string;
  message?: string;
  status?: string;
  type?: string;
  firstSeen?: string;
  lastSeen?: string;
  [k: string]: unknown; // For those unexpected Wonderland surprises
}
Enter fullscreen mode Exit fullscreen mode
  • Backend: handlers, API contracts, validation: 
export interface CreateErrorRequest {
  message: string;
  stack?: string;
  type?: string;
  apiKey?: string;
  projectId?: string;
  user?: string;
}
Enter fullscreen mode Exit fullscreen mode
  • Build configs and types for external libraries

📁 Key changes and approach:

  • Moved shared types into a single module so that front and back use the same data model.
  • Enabled strict: true in tsconfig and did a gradual migration using allowJs.
  • Added types for API responses and log structures.

📁 What I’ve learned (at least, I really hope so!):

✔️ Types act as documentation and prevent errors at early stages.
✔️ Iterative migration with small PRs saves time.
✔️ Shared types between layers reduce the number of runtime errors.

❗ Conclusion: A total brain-melt and "bleeding eyes" are guaranteed for quite some time!

You can find the code and all the details here: https://github.com/kate8382/error-logger-viewer.git

"Thank you for reading my Alice-inspired journey! I’m still looking for answers to the 4 questions above. If you have any thoughts, experiences, or even the wildest metaphors to share, I’d be happy to hear them in the comments!"

Top comments (0)