bob.ts

Posted on Jun 28, 2019 • Edited on Sep 24, 2019

Vanilla TypeScript (gts)

#typescript #javascript #google #bikeshedding

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

Futile investment of time and energy in discussion of marginal technical issues.
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

Top comments (8)

Sophie The Lionhart • Jun 28 '19

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.

bob.ts • Jun 28 '19

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.

Unfortunately, I didn't find this on a quick search.
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!

Elarcis • Jun 29 '19 • Edited

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;
  }
}

bob.ts • Jun 29 '19

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

Bizzycola • Jun 28 '19

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.

bob.ts • Jun 28 '19

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.

Viacheslav Dobromyslov • Aug 14 '20

Thank you for your story sharing.

I gave gts a try in one of my projects for cloud functions and it was also rather complicated. gts still has some nasty bugs like wrong CRLF handling in files managed by Git and linting files in compiler output directory and also I had to manually install eslint with eslint-plugin to make 'npm run check' work.

Another funny observation is a commit history of the gts. There is no actively involved maintainer because issues and pull requests hang without answers for a long time and most active contributor is a bot. I hope devs from the Google Node.js team will not drop this project.

What can I say about alternatives? I experience warm feelings with XO linter. It has slightly complicated initial configuration but received results are worth it.

bob.ts • Aug 15 '20

Thanks for the information. Glad you liked the article. Unfortunately, it was written a while ago and it seems things have changed.

I will definitely look into XO linter one of these days.

DEV Community

Vanilla TypeScript (gts)

Bike shedding?

What is gts?

From Their Documentation: HERE.

What Does This Mean

My Experience with gts ...

TypeScript Issues ...

Conclusions

Image (Cover)

Top comments (8)

Read next

JavaScript Memory Management and Optimization Techniques for Large-Scale Applications

My First JavaScript Web App: Interactive Image Coordinate Finder

Unit, Integration, and E2E Testing in One Example Using Jest

How to Generate and Verify OTPs in Next.js