loading...
Cover image for Vanilla TypeScript (gts)

Vanilla TypeScript (gts)

rfornal profile image bob.js Updated on ・3 min read

I started a new personal project recently. Development moved along smoothly, at first. Then, I realized that I really wanted the type checking that is provided with TypeScript. Having worked with TypeScript in the past, I knew what I wanted ... the question was how to get there.

It is easy to work with TypeScript using a framework where the starter project includes it. But what about a simple TypeScript project that would otherwise be just a vanilla JavaScript project?

In my early research, I came across Google TypeScript Style (gts).

gts is Google's TypeScript style guide, and the configuration for our formatter, linter, and automatic code fixer. No lint rules to edit, no configuration to update, no more bike shedding over syntax.

Bike shedding?

Noun
bikeshedding

  1. Futile investment of time and energy in discussion of marginal technical issues.
  2. Procrastination.

What is gts?

From Their Documentation: HERE.

gts is Google's TypeScript style guide, and the configuration for our formatter, linter, and automatic code fixer. No lint rules to edit, no configuration to update, no more bike shedding over syntax.

To borrow from standardjs:

  • No configuration. The easiest way to enforce consistent style in your project. Just drop it in.
  • Automatically format code. Just run gts fix and say goodbye to messy or inconsistent code.
  • Catch style issues & programmer errors early. Save precious code review time by eliminating back-and-forth between reviewer & contributor.
  • Opinionated, but not to a fault. We recommend you use the default configuration, but if you need to customize compiler or linter config, you can.

Under the covers, we use tslint to enforce the style guide and provide automated fixes, and prettier to re-format code.

What Does This Mean

To me, this means that I can start up a preconfigured opinionated TypeScript project that might need some minor adjustments, but basically is ready to go.

Also, I think it's good to call out that this documentation is incorrect in a few areas (acceptable in my opinion) and there is this quote at the bottom of the page that I almost missed ...

NOTE: This is not an official Google product.

My Experience with gts ...

Installation was as simple as ...

$ npx gts init

... which installed the following with Google's patterns ...

  • package.json
  • tsconfig.json
  • tslint.json
  • prettier.config.js

The gts documentation also says that "If a source folder is not already present it will add a default template project." In my case, a template project was not installed; which was fine since I was moving another project into this space.

I then copied over my code from a previous Vanilla JavaScript project and created a .ts file. And, this is where things got more interesting; I will detail a few issues ... most of the problems had to do with converting to TypeScript from this point.

TypeScript Issues ...

console.log was throwing an error in my code (couldn't find it) ... based on a quick search, I ran ...

$ npm install @types/node

Also, anywhere I was using window to reference elements of the global object in the browser I was getting an error ... having seen this one before, I used (<any>window).

Additionally, I adjusted package.json to include a build processes that would align better with my project and handled a few of other issues converting JavaScript to TypeScript.

Conclusions

When I first started the project and realized I wanted to use TypeScript moving forward, I did a quick search and found Setting Up a New TypeScript Project on alligator.io. Great article, but ALL THOSE STEPS that I don't want to repeat every time I want to jump into some small project with TypeScript in it.

But wait ... at the bottom of the article was Making Things Even Easier: Enter gts.

From all that, I found a pattern that works reasonably well without all the crazy steps to get a Vanilla TypeScript project going!

Image (Cover)

Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY

Posted on by:

rfornal profile

bob.js

@rfornal

REAL, FUN, GEEK who is passionate about Front-End!

Discussion

markdown guide
 

Getting a vanilla TS project going should be as simple as:

npm init
npm install typescript @types/node
npx tsc --init

After that you need to decide which linter to use if any, among other tools and libraries, but that sets up a basic TS project for you. You still need to decide if you're gonna use webpack or babel or whatever, though TS can handle a lot of that for you too. Going through their configuration documentation will show a lot of cool things you can do with just the TS compiler.

Also I don't think you need to do <any>window in TS because there's no need to do window.whatever I do believe. Though without a code snippet perhaps I misunderstood you and am wrong.

 

I'll look at that option; this article was something I came across ... perhaps I'll run this pattern on the next project I do. The article I found that generated this one was two years old and piqued my curiosity.

  1. Unfortunately, I didn't find this on a quick search.
  2. I did find something interesting I wanted to try out.

As to <any>window ... there is a specific need within my project (which will be made public soon, not yet).

Thanks for the "food for thought," awesome information!

 

There is a way to extend the Window interface and declare the type of your globals so that you don't lose TS's help (using any should always be avoided):in a typings.d.ts file possibly at the root of your source folder, write something like that:

declare global {
  interface Window {
    myGlobal: string;
  }
}

Elegant. I’ve gone through a few other things. I’ll try it out.

 

Thanks for the writeup and the info!

I too recently tried to setup a vanilla TS project(something in which a framework like vue or react was much more than I needed), and struggled to even find a good guide on it myself. It ended up taking me a good few hours to setup a basic project.

Good to know there's a much simpler way to do it going forth.

 

Glad to know I'm not the only one that struggled with this a bit. As in your case, any of the frameworks or tools included way more than I needed.

I'm not even sure that this is the best way; it's just one of the first "simple" patterns I found. As I move forward on some of these smaller side projects, I'll document other resources I find, as well.