re-enable gts check and linting

[JustinBeckwith]

The work here is to get npx gts fix passing. Then the lint command should do a gts check, and the fix command should do a gts fix. This will be a very large change, so it's ok to do it in small chunks.

[vijay-qlogic]

@JustinBeckwith type "any" is in use at multiple places, and as per "/tslint.json" which extends "gts/tslint.json", follows "no-any" rule.

At some places it's hard to decide if type "any" should be removed,
like: src/subscriber.ts ln 129 col 67

Shall I set rule { "no-any": false } in "tslint.json"?

[JustinBeckwith]

Heh, nah. This is going to hurt. What you do is set noImplicitAny to true in the tsconfig. That's going to break a lot of stuff. You start with one file, and add types to fix pretty much all of the ambiguous types. Then, you turn noImplicitAny back off, and submit a PR for just that file.

Here are a few examples of repos that have been transitioned in this way:

• https://github.com/googleapis/nodejs-translate
• https://github.com/googleapis/nodejs-storage
• https://github.com/googleapis/nodejs-bigquery

It's admittedly a tad tedious. Generally the only places you should use any are in tests.

[vijay-qlogic]

@JustinBeckwith Thanks!
But raising PR for individual file-change my break the stuff, for changes like:
export class IAM { Promise?: PromiseConstructor;
to
export class IAM { promise?: PromiseConstructor;
that is changing the property name.

Any concerns with raising PR for all changes together?

[JustinBeckwith]

So we absolutely do not want to introduce breaking changes here. In this example, we would us a tslint ignore. Place this on the pine above the property.

// tslint:disable-next-line variable-name

If we don't limit this to one file at a time, the PR will quickly get out of control. I'd the changes to other files are small and required to get basic compilation going that's fine.