<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: Valentin MELUSSON</title>
    <description>The latest articles on Forem by Valentin MELUSSON (@valentinmelusson).</description>
    <link>https://forem.com/valentinmelusson</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3258002%2F998f4a00-9b72-4ecd-a321-169041172007.jpeg</url>
      <title>Forem: Valentin MELUSSON</title>
      <link>https://forem.com/valentinmelusson</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/valentinmelusson"/>
    <language>en</language>
    <item>
      <title>Why Scaling TypeScript Became a Necessity at Datadog</title>
      <dc:creator>Valentin MELUSSON</dc:creator>
      <pubDate>Fri, 04 Jul 2025 07:40:55 +0000</pubDate>
      <link>https://forem.com/datadog-frontend-dev/why-scaling-typescript-became-a-necessity-at-datadog-1nmn</link>
      <guid>https://forem.com/datadog-frontend-dev/why-scaling-typescript-became-a-necessity-at-datadog-1nmn</guid>
      <description>&lt;p&gt;This post is the first in a series in which we'll be detailing the various methods we've used to scale TypeScript despite the size of our big - and ever-growing - repository.&lt;/p&gt;

&lt;p&gt;The idea behind this series is to share the solutions we've implemented and the thoughts that have guided us, with the aim of inspiring other teams, fostering exchanges with the community and, why not, sparking enriching feedback or discussions. Now let's go back to today's topic : &lt;strong&gt;why scaling TypeScript became a necessity at Datadog&lt;/strong&gt; ?&lt;/p&gt;




&lt;p&gt;At &lt;a href="https://www.datadoghq.com/" rel="noopener noreferrer"&gt;Datadog&lt;/a&gt;, our frontend codebase has historically enjoyed quick developer cycle times. Fast &lt;a href="https://aws.amazon.com/devops/continuous-integration/" rel="noopener noreferrer"&gt;CI&lt;/a&gt; jobs, responsive &lt;a href="https://www.codecademy.com/article/what-is-an-ide" rel="noopener noreferrer"&gt;IDE&lt;/a&gt;s, and the TypeScript tooling performed well. This allowed teams to ship products &amp;amp; iterate quickly.&lt;/p&gt;

&lt;p&gt;As members of &lt;a href="https://dev.to/yoannmoinet/developer-experience-magna-carta-2eak"&gt;developer experience&lt;/a&gt; teams whose clients are internal developers, one of our goals is to ensure that development remains fast and safe as the organization and its codebase continues to grow.&lt;/p&gt;

&lt;h2&gt;
  
  
  A Codebase That Keeps Growing
&lt;/h2&gt;

&lt;p&gt;To give some perspective about the growth of our repository: in June 2025, our frontend codebase was made of over &lt;strong&gt;11 million lines&lt;/strong&gt; of TypeScript across more than &lt;strong&gt;95,000&lt;/strong&gt; &lt;code&gt;.ts&lt;/code&gt; and &lt;code&gt;.tsx&lt;/code&gt; files. One year earlier, we only had around &lt;strong&gt;6 million lines&lt;/strong&gt; in &lt;strong&gt;65,000&lt;/strong&gt; files. &lt;/p&gt;

&lt;p&gt;That doubling trend has been consistent since at least 2021, and we are still looking at significant growth over the next few years. (~ doubling every 12 to 18 months)&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F16w4icjpzghwhk5x0pu6.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F16w4icjpzghwhk5x0pu6.png" alt="Evolution of the number of Typescript LoC over time, with forecast" width="800" height="365"&gt;&lt;/a&gt;&lt;small&gt;&lt;em&gt;This graph with &lt;a href="https://www.datadoghq.com/blog/forecasts-datadog/" rel="noopener noreferrer"&gt;forecast&lt;/a&gt; is from one of our &lt;a href="https://docs.datadoghq.com/dashboards/" rel="noopener noreferrer"&gt;Datadog monitoring dashboard&lt;/a&gt;&lt;/em&gt;&lt;/small&gt;&lt;br&gt;
&lt;br&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  The Impact of Growth
&lt;/h2&gt;

&lt;p&gt;This growth brought a number of challenges:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Typechecking&lt;/strong&gt;, as well as other jobs such as linting, running tests, etc... that are mandatory to make any change to production, are all &lt;strong&gt;increasingly taking longer in CI&lt;/strong&gt; and slowing down our ability to ship features or fixes (see following graph). Their increase in duration was also correlated to the number of lines of code in the codebase, which is a clear scalability problem. &lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fzz3xcyjg6spg8vdldx1a.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fzz3xcyjg6spg8vdldx1a.png" alt="Typecheck duration over time" width="800" height="548"&gt;&lt;/a&gt;&lt;small&gt;&lt;em&gt;This graph is from one of our &lt;a href="https://docs.datadoghq.com/dashboards/" rel="noopener noreferrer"&gt;Datadog monitoring dashboard&lt;/a&gt;&lt;/em&gt;&lt;/small&gt;&lt;br&gt;
&lt;br&gt;  &lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;In IDEs, the &lt;a href="https://github.com/microsoft/TypeScript/wiki/Standalone-Server-%28tsserver%29" rel="noopener noreferrer"&gt;&lt;strong&gt;&lt;code&gt;TS server&lt;/code&gt;&lt;/strong&gt;&lt;/a&gt; was getting slower, resulting in delays for core features like type error display, autocompletion, “Go to definition,” and “Find references.” This led to a noticeably &lt;strong&gt;poorer developer experience&lt;/strong&gt;.
&lt;/li&gt;
&lt;/ul&gt;

&lt;blockquote&gt;
&lt;p&gt;To give a clearer picture, the &lt;a href="https://baselime.io/glossary/p90" rel="noopener noreferrer"&gt;P90&lt;/a&gt; loading time of the &lt;code&gt;TS server&lt;/code&gt; in our IDEs is currently &lt;strong&gt;6s&lt;/strong&gt;, but has peaked as high as &lt;strong&gt;2min&lt;/strong&gt;. Similarly, autocompletion latency currently sits at a P90 of &lt;strong&gt;662ms&lt;/strong&gt;, with past peaks reaching &lt;strong&gt;6.6s&lt;/strong&gt; seconds&lt;/p&gt;
&lt;/blockquote&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Support requests&lt;/strong&gt; from developers related to &lt;strong&gt;TS performance&lt;/strong&gt; in CI or in the IDEs were increasing.&lt;br&gt;
&lt;br&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;CI jobs became &lt;strong&gt;costly&lt;/strong&gt; and &lt;strong&gt;consumed more resources&lt;/strong&gt; as they were running for a bigger codebase and taking longer.&lt;br&gt;
&lt;br&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Understanding dependencies across teams got harder&lt;/strong&gt;. As the number of teams and products was growing, so did the complexity of the dependency graph. This led to larger bundles, performance regressions, and a higher risk of incidents due to hidden coupling. &lt;br&gt;
&lt;br&gt;&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h2&gt;
  
  
  Understanding the signals
&lt;/h2&gt;

&lt;p&gt;All the mentioned signals showed us that we needed to &lt;strong&gt;decorrelate the size of the codebase and the dev tooling performance&lt;/strong&gt;. In the case of TypeScript, it means keeping CI jobs performant and maintaining a responsive &lt;code&gt;TS server&lt;/code&gt; in IDEs.&lt;/p&gt;

&lt;p&gt;With our forecast of the codebase &lt;strong&gt;doubling every 12 to 18 months&lt;/strong&gt; for the next few years, it was imperative that we take proactive steps — not only to address the current situation, but also to support our &lt;strong&gt;future growth&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;While everything was still manageable, we knew that waiting would only make the problems harder to solve. We decided to act early, investing in structural, setup, and tooling improvements to keep the development experience strong as we scale.&lt;/p&gt;

&lt;p&gt;In the next post in this series, before looking at the concrete ideas and solutions we've put in place, we'll focus on an essential subject (especially for us since we're &lt;a href="https://www.datadoghq.com/" rel="noopener noreferrer"&gt;Datadog&lt;/a&gt;): &lt;strong&gt;monitoring&lt;/strong&gt;. We'll detail how, and to what extent, we observe the performance of our &lt;strong&gt;&lt;code&gt;TS server&lt;/code&gt;&lt;/strong&gt; and CI jobs to detect signals and guide our decisions.&lt;/p&gt;

</description>
      <category>typescript</category>
      <category>datadog</category>
      <category>programming</category>
      <category>performance</category>
    </item>
  </channel>
</rss>
