Master TypeScript Project Setup with JavaScript and GTS

Introduction

Setting up a project with TypeScript, JavaScript, and Google TypeScript Style (GTS) is the foundation for building cleaner, more maintainable code. This guide walks you through configuring TypeScript from scratch, compiling it into JavaScript, and integrating GTS for consistent, high-quality code formatting. By mastering this workflow, developers can streamline their setup process, enhance linting precision, and follow best practices for scalable TypeScript projects.

Step 1 — Starting the TypeScript Project

Alright, let’s get your typescript project rolling! The first thing you’ll want to do is create a new folder that’s going to be home to everything you build. Think of it like setting up a workspace where all your files, configurations, and compiled javascript code can live happily together.

Open your terminal and run this command:

$ mkdir typescript-project

Once that’s done, go ahead and jump into that directory with:

$ cd typescript-project

This simple move ensures that everything you install or configure will stay neatly inside this one folder instead of spreading across your whole computer. Trust me, keeping things scoped here saves you headaches later.

Now that your workspace is ready, it’s time to install TypeScript. This step gives you all the tools you need to write and compile your TypeScript code into JavaScript. Run this command:

$ npm i typescript –save-dev

Here’s the thing, that --save-dev flag might look small, but it’s pretty important. What it does is tell your system that TypeScript is a development dependency, meaning it’s only needed while you’re coding—not when your app goes live. This keeps your final deployment light and efficient but still gives you everything you need to code like a pro during development.

Once TypeScript is up and running, it’s time to officially initialize your project. Think of this as flipping the switch that tells your system, “Hey, we’re doing TypeScript here!” You can do that with this command:

$ npx tsc –init

Now, npx is like your handy assistant that comes built into npm. It lets you run executables right from your project without needing to install them globally. It’s especially great when you’re juggling multiple projects that might need different versions of tools.

The tsc part stands for “TypeScript Compiler,” and that’s the magic command that turns your TypeScript files ( .ts ) into JavaScript files ( .js ).

When you add the --init flag, this command automatically creates a file called tsconfig.json inside your project folder. This file is super important because it tells the compiler how to behave. It includes options for where your compiled code should go, what version of JavaScript to target, and even how your modules should be resolved. Having this file keeps your build process predictable, no matter which computer or teammate is working on it.

Want to peek inside and see what’s happening? Open it up in your favorite text editor:

$ nano tsconfig.json

When you open it, you’ll see a bunch of options, many of them commented out. Don’t worry, that’s totally normal. The file is designed to give you flexibility without overwhelming you right away. Here’s a little sneak peek of what it looks like:

typescript-project/tsconfig.json
{
  “compilerOptions”: {
    /* Visit https://aka.ms/tsconfig.json to read more about this file */
    /* Projects */
    // “incremental”: true,                                    /* Enable incremental compilation */
    // “composite”: true,                                         /* Enable constraints that allow a TypeScript project to be used with project references. */
    // “tsBuildInfoFile”: “./”,                                         /* Specify the folder for .tsbuildinfo incremental compilation files. */
    // “disableSourceOfProjectReferenceRedirect”: true, /* Disable preferring source files instead of declaration files when referencing composite projects */
    // “disableSolutionSearching”: true,                                                       /* Opt a project out of multi-project reference checking when editing. */
    // “disableReferencedProjectLoad”: true,                                                       /* Reduce the number of projects loaded automatically by TypeScript. */
    …
  }
}

Each of those lines does something specific. For example, turning on incremental makes your recompilations faster because TypeScript remembers what it did before. The composite option is super handy if you’re dealing with multiple projects that depend on one another.

You can also tweak a few things to make your setup feel more your own. One helpful tip is to uncomment the outDir option and set it to "./build" . That way, when your TypeScript compiles into JavaScript, all those generated files land neatly in a separate folder instead of mixing with your source files. Keeping your .ts files separate from your .js files keeps everything cleaner and easier to manage.

Once you’ve got TypeScript installed and your tsconfig.json ready, you’ve officially built the foundation of your project. You can start writing code in .ts files and then compile it into JavaScript whenever you’re ready.

Step 2 — Compiling the TypeScript Project

Alright, time to dive into some real typescript action! You can now start coding your typescript project using the setup you created in the previous step. This part is where you’ll finally write your first file, compile it into javascript, and see how the typescript compiler works its magic to turn your code into something browsers and servers can actually run.

So, here’s what you’ll do. Open up your favorite code editor and create a brand-new file called index.ts . This little file is going to be the heart of your project—it’s your starting point where all the fun begins. Go ahead and drop in this code:

typescript-project/index.ts

const world = ‘world’;
export function hello(who: string = world): string {
    return `Hello ${who}! `;
}

Pretty simple, right? Yet, it’s powerful. This short but clever snippet shows off typescript’s ability to use type annotations and default parameter values. Basically, the hello function can take an argument named who that’s always expected to be a string. But here’s the neat part—if you don’t pass anything in, it’ll just default to 'world' . The function then gives you a cheerful greeting using template literals, which makes your code cleaner and easier to read. You could say this little piece of code is a great example of typescript’s love for type safety and readability. It helps keep your code neat, less buggy, and easy to understand for anyone who works with it later.

Once your typescript code is saved, it’s showtime! Now your project is ready to be compiled. Compilation might sound fancy, but it’s basically just turning typescript files (those .ts ones) into javascript files (the .js ones) so that browsers or Node.js can understand them. To get this rolling, open your terminal and run this command:

$ npx tsc

When you hit enter, the typescript compiler will look inside your tsconfig.json file to see how you’ve set things up. It’ll then transform your .ts files into .js and save the results wherever your configuration says they should go. If earlier you set the outDir in your config to ./build , then you’ll see your brand-new compiled files appear right there in that folder.

Now, what does the compiler actually give you? Two handy files:

• An index.js file, which contains your javascript code ready to run.
• And an index.js.map file, which helps you debug your original typescript while working with your compiled javascript.

This source map is like a translator that points you back to the exact TypeScript line when something goes wrong.

Let’s take a look at what your compiled javascript might look like:

typescript-project/build/index.js

“use strict”;
Object.defineProperty(exports, “__esModule”, { value: true });
exports.hello = void 0;
const world = ‘world’;
function hello(who = world) {
    return `Hello ${who}! `;
}
exports.hello = hello;

Not too scary, right? This is your typescript code transformed into a form that javascript environments understand perfectly. The "use strict"; line ensures that your code runs in strict mode, which is a safety feature in javascript that catches sneaky bugs early on. The exports lines at the bottom? Those make your hello function reusable, meaning you can import it into other files whenever you want. It’s a great example of how typescript keeps your code modular and organized while smoothly converting it into usable javascript.

But let’s be honest—running the compiler manually every time you tweak a file can get tiring pretty quickly. No one wants to retype npx tsc fifty times a day. Luckily, typescript has your back with something called “watch mode.” This handy feature automatically keeps an eye on your files and recompiles them whenever you make changes. To turn it on, just run:

$ npx tsc -w

Once watch mode is active, typescript will quietly monitor your source files in the background. Every time you save a change, it instantly recompiles the updated code. It’s like having a super-efficient assistant who’s always on duty making sure your code is up to date. This little trick makes development way smoother and helps you focus more on building rather than babysitting your compiler.

So now, you’ve learned how the typescript compiler works, how to turn your .ts files into working javascript, and how to use features like source maps and watch mode to keep things flowing. By the way, this setup is already efficient, but we can make it even better.

At this stage, your typescript project is running smoothly and ready for the next level. To make it even more professional, you’ll soon bring in a linter. Think of it as your friendly code coach that automatically checks for small mistakes, weird formatting, or anything that breaks consistency. Adding a linter (like the one that comes with google typescript style, known as gts ) helps you catch errors before they become real problems and keeps your code clean, reliable, and easy to maintain as your project grows.

Read more about content best practices TypeScript Handbook: Compiler Options and Configuration (2025)

Step 3 — Using Google TypeScript Style to Lint and Correct Your Code

Alright, let’s talk about something that might sound a bit technical but is actually super helpful for keeping your TypeScript projects clean and professional. Using a linter when you’re coding is like having a friendly proofreader for your code. It helps you spot typos, weird spacing, or little mistakes before they turn into actual bugs. It’s also great for keeping your code readable, consistent, and easy for others to understand.

You see, a linter is basically a tool that scans your code for potential problems, such as syntax errors or formatting issues. It’s like that colleague who gently taps you on the shoulder and says, “Hey, you missed a semicolon there.” By adding a linter to your workflow, you can fix issues before they sneak into your app and cause headaches later.

Now, there’s also something called a style guide, and it works hand in hand with your linter. Think of it like a shared rulebook for how your team’s code should look—how it’s spaced, how variables are named, and how functions are structured. This is especially important when multiple people are working together on the same project because it keeps everything looking neat and uniform. Plus, having a consistent TypeScript code style makes your life way easier when you come back months later and try to remember what you were doing.

One of the most popular tools to manage all this is ESLint . You might’ve heard of it—it’s basically the linter superhero for modern development. ESLint works beautifully with most IDEs, meaning as you type your TypeScript code, it gives you real-time hints, warnings, and even automatic fixes. It’s like spellcheck for your programming life.

So, now that your TypeScript project is all set up and humming along, you can take things to the next level by bringing in more tools to simplify your workflow. Rather than fiddling with configurations and rules inside tsconfig.json , you can use something that does the heavy lifting for you—Google TypeScript Style, also known as gts .

Google TypeScript Style ( gts ) is like a one-stop shop for keeping your code sharp. It’s a style guide, linter, and formatter rolled into one handy package. It was created to help developers quickly launch new TypeScript projects while still sticking to industry best practices. The great thing about gts is that it takes care of the boring setup work for you so you can spend more time actually writing cool stuff instead of getting lost in configurations.

One of the things that makes gts so awesome is that it comes with its own ready-made configuration. It’s what’s called “opinionated,” which just means it has a strong set of default rules based on years of developer experience. You don’t have to start from scratch or tweak much at the beginning—it just works right out of the box. And if you ever want to fine-tune it later, you totally can.

To get gts installed, open your terminal and run:

$ npm i gts –save-dev

That’s it! This command adds gts to your development environment, giving you access to all of its linting and formatting tools. Once that’s done, initialize it by typing:

$ npx gts init

When you run that, gts sets everything up for you automatically. It creates all the important configuration files, like tsconfig.json , a linting setup, and even a package.json if you don’t already have one. It’s basically like pressing the “easy button” for your project setup.

Even better, once you’ve initialized it, gts adds handy npm scripts to your package.json file. These scripts make it super easy to do common tasks, such as compiling your code or checking for linting errors. For example, to compile your project, you can run:

$ npm run compile

And to check for linting issues or formatting mistakes, just run:

$ npm run check

These little commands save time and keep your workflow consistent. No more typing long commands or remembering complex setups—just quick and simple shortcuts that work every time.

Sometimes gts might lag behind TypeScript updates a bit, so it might suggest you downgrade your version. If that happens, don’t panic—you can tell gts to leave your setup as is. It’s usually fine, especially if you’re using newer features.

Also, gts uses ESLint under the hood, and the ESLint plugin for TypeScript supports a specific range of TypeScript versions. So, if you happen to be using a newer version that’s not officially supported yet, ESLint might show a small warning. Most of the time, everything will still work perfectly. But if something weird happens, you can always downgrade to a version that’s guaranteed to play nicely. For example, you can install a specific version like this:

$ npm i [email protected] –save-dev

Once that’s sorted, gts will be fully integrated into your TypeScript project. You’ll now have a professional-grade linting and formatting system built right in. It’s like having a personal assistant who keeps your code tidy and error-free while you focus on building cool stuff.

And here’s the best part—when you use gts for your future TypeScript projects, you won’t have to redo all that setup ever again. You can just run the same commands and boom, everything’s ready to go. It’s fast, efficient, and keeps your codebase in tip-top shape.

Now, even though gts is mostly automatic, you’re still in control. If you ever feel like adjusting some of its built-in rules to fit your own project or team preferences, it’s super easy. Just create a file called .eslintrc in your project folder and extend the existing Google TypeScript Style configuration like this:

extends:
  – ‘./node_modules/gts’

This setup lets you tweak the default Google TypeScript Style rules however you like. Maybe you prefer different indentation, naming conventions, or spacing—it’s all up to you. You’re still following best practices but with your own flavor on top.

So, to wrap this up, using Google TypeScript Style with gts gives you a big productivity boost. You get automatic linting, consistent formatting, and built-in coding standards—all without needing to mess around with complex configurations. It keeps your TypeScript and JavaScript projects looking sharp, working smoothly, and ready for teamwork.

Read more about content best practices Google TypeScript Style Guide (GTS) on GitHub (2025)

Conclusion

Mastering TypeScript, JavaScript, and Google TypeScript Style (GTS) gives developers full control over how they build, compile, and maintain clean, consistent code. By learning how to manually configure and initialize a TypeScript project, you gain the flexibility to customize every part of your setup—from directory structure to linting rules—without depending on starter templates or frameworks.

With GTS integrated, your workflow becomes smoother, ensuring standardized formatting, powerful linting, and long-term scalability for any TypeScript-based application. As modern development continues to evolve, staying familiar with these tools and practices will help you write better code, collaborate more effectively, and adapt to new TypeScript and JavaScript trends in the years ahead.

In short, mastering GTS-driven TypeScript setup today sets the foundation for cleaner, more efficient JavaScript development tomorrow.

Add JavaScript to HTML: Optimize with External .js Files and Defer Attribute (2025)