{"id":4407,"date":"2024-12-30T13:33:32","date_gmt":"2024-12-30T18:33:32","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=4407"},"modified":"2024-12-30T13:33:33","modified_gmt":"2024-12-30T18:33:33","slug":"typescript-without-build-tools","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/typescript-without-build-tools\/","title":{"rendered":"TypeScript without Build Tools"},"content":{"rendered":"\n

TL;DR:<\/strong> There are a bunch of tools<\/a> these days that allow you to write in TypeScript and… just not think about it<\/em> much more than that. You needn’t deal with converting that code into JavaScript yourself.<\/p>\n\n\n\n

\n\n\n\n

Here’s what has me thinking about all that.<\/p>\n\n\n\n

We’ve got a monorepo at work<\/a>.<\/p>\n\n\n\n

We’ve been moving to TypeScript for years, with mostly positive results. I’m fairly convinced that the code output from writing in TypeScript is better and the experience of writing and editing existing TypeScript code is better DX.<\/p>\n\n\n\n

It’s not without challenges though. I hate wasting time futzing with types when I just know it really isn’t improving the quality of my code I’m just fighting with a machine. This concern is multiplied when you see your team doing the same thing. <\/p>\n\n\n\n

Another challenge is the part where you actually have to produce JavaScript<\/strong>. This is not a difficult job in and of itself. There are loads of tools that do this from the canonical tsc<\/code><\/a> to tools that do no type checking but can very speedily compile TS to JS (like esbuild<\/a>). But sometimes, you still have to do<\/em> it.<\/p>\n\n\n\n

One example from our monorepo is that we have some components that we’d like to write in .tsx<\/code>, but they can be consumed by a number of different site building tools (e.g. a Next.js site, an Astro site, an classic Just Load React On The Page site, etc). The most sane way of handling this is processing the TS into JS ahead of time. That way whatever site that wants to import them can do it as native, normal JavaScript ESM stuff.<\/p>\n\n\n\n

monorepo
  website-1
  website-2
  packages
    components
      dist
        MyVeryImportantComponent
          index.js
      src
        MyVeryImportantComponent
          index.tsx   <\/pre>\n\n\n\n
Now I need to make a build process<\/strong> to do this. I’ll probably write a little script. npm run process-packages<\/code> or whatever, fine. I’ll probably use tsc<\/code> for this on purpose, knowing that it isn’t the fastest, but it’s the one that is capable of actually throwing errors when there are TypeScript problems. This is useful because I can call my script in a pre-commit hook in Git, for example, to prevent myself and my team from committing bad TypeScript. I can call the script in CI as well which is additional protection.<\/p>\n\n\n\n
So now I have tsc<\/code> building from src<\/code> to dist<\/code>, great. But TypeScript explicitly will never build an “other files” copy machine<\/a>. Well that’s annoying. What about my other stuff?<\/p>\n\n\n\n
packages
  components
    src
      MyVeryImportantComponent
        index.tsx
        queries.graphql
        styles.module.scss<\/pre>\n\n\n\n
Now I have to wire up some new<\/em> machine to copy anything that isn’t TypeScript over from src<\/code> to dist<\/code>. Blech. Fine, I’ll do it. <\/p>\n\n\n\n
But this is all complicated by the fact that this script we’re building needs to be able to run two ways:<\/p>\n\n\n\n
    \n
  1. As a builder, where you call it and it does the job<\/li>\n\n\n\n
  2. As a watcher, where it runs the build when any pertinent file changes<\/li>\n<\/ol>\n\n\n\n
    It’s unacceptable DX to expect a developer to run a build command after every file change manually. So we have to build our own little watcher too. I guess it’s Chokidar<\/a> time? I hate piling on dependencies, but that’s the only watcher that’s ever felt truly reliable to me.<\/p>\n\n\n\n
    I don’t mean to paint this picture too negatively. This is all doable. This is the job.<\/em> There are tools to help with this that get better over time. But wow, it’s a lot when you consider it was just TypeScript, this invisible layer of special code helping syntax, that pushed us this far into toolsville. <\/p>\n\n\n\n
    I’d rather focus on the positive stuff I’m seeing here. As the years tick by, and TypeScripts popularity remains high, the surrounding tools that deal in JavaScript are more and more fine with “just leave it as TypeScript.” I find that interesting! <\/p>\n\n\n\n
    This “native” support of TypeScript is a product choice. We know some of our customers write and prefer TypeScript so we’ll make it easier for them.<\/em> But there is no Official\u2122 way to do this. The product needs to decide how they are going to handle it. Are they going to check types for you and alert you (somehow? somewhere?) to type problems? Or are they leaving type problems to you, and if the code compiles to JavaScript, so it shall be. What version of TypeScript is it going to support? Is configuration necessary?  <\/p>\n\n\n\n
    So what are these products?<\/p>\n\n\n\n
    Tools & Products That Let You Write TypeScript “Natively”<\/h2>\n\n\n\n
    Frameworks<\/h3>\n\n\n\n