TypeScript: Allow more constructs to work as type guards for `unknown`

I would like it if type guards with unknown worked a little more like this.

let x: unknown

if (typeof x === 'object' && x !== null && 'foo' in x && typeof x.foo === 'string') {
  /* x is promoted to {foo: string} here */
}

I think the type promotion ought to work like so, if at all possible.

1. typeof unknown === 'object' -> object | null
2. (object | null) !== null -> object
3. 'foo' in object -> {foo: unknown}
4. typeof {foo: unknown}.foo === 'string' -> {foo: string}

Until this is fixed, this is a helper that can be used to make it easier to write manual type guards for unknown types that you expect to be nested objects:

export function isUnknownObject(x: unknown): x is { [key in PropertyKey]: unknown } {
  return x !== null && typeof x === 'object';
}

Example usage:

function example(x: unknown) {
    if (isUnknownObject(x) && isUnknownObject(x.prop) && typeof x.prop.subProp === 'string') {
        console.log(x.prop.subProp);
    } else {
        console.log('Could not find subProp');
    }
}

example({
    prop: {
        subProp: 'test',
    }
});
example({});

For more complicated use cases, using something like https://github.com/gcanti/io-ts is probably a better option than writing the type checks manually, but isUnknownObject can be useful for simple cases.

Would like to see this implemented.

function isTest(arg: unknown): arg is Test {
  return (typeof arg === "object") && (arg !== null) &&
    ("quest" in arg) && (typeof arg.quest === "string");
}

interface Test {
  quest: string;
}

Typescript still complains for the above code even though we check for all the cases before accessing the quest property.

Using any instead of unknown takes away the benefits of using TS in the first place.

And one more thing:

let foo: unknown;
if (typeof foo === "object") {
	// foo should probably be narrowed to {[prop: string]: unknown} here
}

At the least, at typeof foo === "object" it should narrow to object. Currently remains unknown and the following fails:

function f(u: unknown): object { return typeof u === "object" ? u : {}; }

I’d also like to add that unknownValue instanceof Array should really be refined to unknown[], not any[] as is the current behavior. I’m also not getting warnings about implicit any when I do that.

The lack of better/easier type guards for unknown type is why I’m not using it in try…catch blocks as well. I should be able to do simply

catch (e: unknown) {
  console.log(e?.message);
}

I don’t want to overcomplicate my code just because unknown is so hard to work with so I’m sticking to any, yet I’d happily use unknown if the code above and in the other proposed examples worked.

I would expect ?. to work as well with an unknown err, though perhaps there’s a case I haven’t thought of which would cause failure, eg:

if (err?.message) {
  // err is typed as { message: unknown, [k: string]: unknown }, or similar. 
}

I was hoping unknown would let me have type-safe data-loading, e.g.:

interface SomeValue { a: string, b?: number, c: 'left' | 'right' }
function readValue(id: string): SomeValue {
  const u: unknown = await someDataSource(id);
  if (
    typeof u !== 'object' ||
    u === null ||
    typeof u.a !== 'string' ||
    b in u && typeof u.b !== 'number' ||
    u.c !== 'left' && u.c !== 'right'
  ) {
    throw new Error(util.format('Invalid value with id %O from some data source: %O', id, u));
  }

  return value; // TS is checking that the checks above actually verify the return type here
}

This to me would be a better match to TS for what #26078 wants, but I wouldn’t complain about adding quick-fixes to add the missing checks!

(remember that typeof u === "object" should actually narrow to object | null - Thanks javascript!)

Yes, naming is not the best I agree (but whatever, you can call it as you want), and to be honest I only use it private in file along with some type guards so my main intention is usage in guards so far.

As you suggested arg as Partial<CommandCreator> doesnt work inlined within the condition e.g.

Whereas with my suggestion works as following:

So again, the main benefit is that F2 rename works (which is a huge plus imo) Anyway just wanted to share.

isAssumedType<CommandCreator>(arg)

This is effectively the same as a type assertion (i.e. arg as Partial<CommandCreator>), but unlike a type assertion it does not use an explicit as keyword and it implicitly changes the type of arg in the following expressions.

Type assertions are fine and have to be used sometimes, but personally I would avoid using something like isAssumedType because 1) it is less explicit so other people reading the code might not realize a type assertion is being made and 2) it makes it very easy and convenient to use type assertions, which is probably a bad thing because type assertions should generally be avoided when possible.

@butchler Similar to what you suggested (infect i started with that)

function isAssumedType<T = Record<string, unknown>>(x: unknown): x is Partial<T> {
	return x !== null && typeof x === "object";
}

// usage
if (isAssumedType<CommandCreator>(arg) && arg.execute && arg.host) {
    return true;
}

The main difference is that arg will be partially typed so when you do checks with props they are bound to the interface so you can F2 rename safely and will also be updated

I realize I’m a bit late, but you might be interested in https://github.com/gcanti/io-ts – provides a nice way to generate your necessary typeguards, though might be a bit heavy handed for the common usecase (and thus probably still worth considering this issue)