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

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
}

• Backend: handlers, API contracts, validation:

export interface CreateErrorRequest {
  message: string;
  stack?: string;
  type?: string;
  apiKey?: string;
  projectId?: string;
  user?: string;
}

• 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!"

Comments

[Rahul Joshi]

Great write-up—the transition to TypeScript can definitely feel like a rabbit hole at first, but the type-safety and developer experience on the other side make the migration so worth it!.

[Ecaterina Sevciuc]

Thanks for the comment, Rahul! You know, looking back, I've come to think it’s better to learn the 'hard but right' way from the start than to relearn later.

When I fully immersed myself in JS, I thought I was getting the hang of it. But then I hit the TS 'rabbit hole' and my brain just started screaming: 'Wait, this isn't how we did it in JS!'. It’s a bit of a crisis — you start doubting if you ever knew JS at all, even though TS is just a superset.

To push through this, I recently migrated my entire sandbox project (Error Logger & Viewer) to TS—from the frontend to the backend and even e2e/unit tests. It’s been a wild ride. 🕳️🤯 🤕

In your experience, do you think it's worth putting beginners through this 'typed' stress early on, or is the JS-first path still the lesser of two evils?

[Rahul Joshi]

That’s a million-dollar question, Katya! In my experience, I’m leaning towards the 'typed stress' early on. While JS gives you immediate gratification, it often builds a false sense of security that breaks at scale. Learning TS first is like learning to drive with mirrors and sensors from day one—it feels restrictive initially, but it prevents a lot of 'accidents' (runtime errors) later. Since you've already migrated your entire sandbox—frontend to E2E—you've essentially built a production-grade safety net. That 'crisis' of doubting your JS skills is actually just your brain upgrading its mental model! 🚀.

[Ecaterina Sevciuc]

That driving analogy is perfect! ✨️ It really feels like I’ve traded a 'fast but risky' bike for a car with a full safety system.

Honestly, it’s a huge relief to know I'm not alone in these doubts. Hearing that experienced developers went through the same crisis makes me realize I’m on the right track, rather than just 'lost in the wrong field'.

Thanks for the support, Rahul — it gives me the confidence to keep going. 🤗
Happy coding!

[Rahul Joshi]

You're definitely on the right track, Katya! That 'aha!' moment usually comes when you go back to a JS project and find yourself missing the types immediately. It’s a one-way street once you realize how much cognitive load TS takes off your plate. Can’t wait to see what you build next—happy coding!