I am torn here, on one hand this is a good change for people that are still using goog.is*, on another hand I rather change gents to replace these with their actual implementations:

isBoolean -> typeof val == 'boolean'

which TypeScript has no problem of type narrowing from. I don't recommend anyone keep using goog.is* in their TS code.

Why not? We find the named functions easier to read than the actual implementation.
Especially isDefAndNotNull and isNull are much easier to tell apart than counting the number of = signs.

Also on a related note, I just discovered that goog.reflect.object also needs a custom type:

function object <T extends{[key:string]:any}>(type : {new(...args:any[]):{[P in keyof T]:any}}, object : T ) : T ;

The autogenerated one is completely useless. It requires casts to any use, which then removes all the type information that Closure Compiler needs for reflection.

Let's get second opinion from @shicks. I think not having this special case will nudge people towards inlining goog.is* and friends which we think is beneficial and more idiomatic going forward.

Are you aware of anything like refasterjs for typescript to help migrate our existing code?
What do you think about adding a special case for goog.reflect.object? The currently generated type is just broken.

@ribrdb about global refactorings, we have been talking about the different options, but for now we just use TSLint with its autofixer API. Also, for these APIs something as simple as 'sed' might suffice.

Closing this as we are moving away from 'goog.is*' functions. I think something similar will be interesting to do once Type assertions land in 3.7 for Closure's assert methods.