https://severinbucher.com/tags/react/Recent content in React on Severin Bucher | BlogHugoenMon, 11 May 2026 00:00:00 +0000https://severinbucher.com/posts/upgrading-a-legacy-monorepo-to-react-18/Mon, 11 May 2026 00:00:00 +0000https://severinbucher.com/posts/upgrading-a-legacy-monorepo-to-react-18/<p>React 18 shipped in March 2022. We merged our upgrade in April 2026. If you do that math, yes, we were four years behind. This is a post about what that upgrade actually looked like across a large, multi-generational codebase, and the specific issues that ate most of the time.</p> <p>Spoiler: the &ldquo;breaking changes&rdquo; in the official React 18 migration guide are the easy part.</p> <h2 id="the-starting-point">The Starting Point</h2> <p>Our frontend isn&rsquo;t one app. It&rsquo;s four generations of React code living in the same monorepo, piled up over years of product growth:</p>https://severinbucher.com/posts/enabling-typescript-strict-mode-in-a-legacy-react-project/Wed, 26 Mar 2025 00:00:00 +0000https://severinbucher.com/posts/enabling-typescript-strict-mode-in-a-legacy-react-project/<p>Our App was created in 2017. It is a React application written in TypeScript. At the time, TypeScript was gaining popularity, but strict type safety wasn&rsquo;t a major concern for most teams. Our knowledge of TypeScript was limited, and the primary goal was to use it for basic type annotations rather than enforcing a fully type-safe codebase.</p> <p>As a result, strict mode was never turned on. The codebase ran without the safeguards strict mode brings: strict null checks, no implicit <code>any</code>, and tighter type inference. As the project grew, that gap started to cost us. Subtle bugs slipped through, and refactoring carried more risk than it should have.</p>