Seems all of the literal types( string, number ...) will be treated as a primitive type at indirectly referring.
Not only in typeof, See #2423 .
it could be nice if literal types will be excluded from primitive type cleanly.

@iamchenxin you are right, they are also not captured by polymorphic functions.

Here's an example of this in action:

Edit: the link I previously had now redirects to an unrelated site.

In TypeScript behaviour depends on type of binding:

const x = 'X';
const y: typeof x = 'Y'; // error

let x = 'X';
const y: typeof x = 'Y'; // no error

To put in another way:

const foo = 'foo'
const bar: typeof foo = 'bar'

Since foo is declared as constant it's not possible to assume that its type is the literal value?

Yes! To me it also seems like it would be much nicer if typeof foo was 'foo', since that would provide more information, and still allow the foo constant to be used everywhere a string was expected. It would be very valuable to have a way to export constants, that other modules can then use for type-refinement.

But what about typeof 'string'?

Or is flow's checking using typeof different then javascripts typeof?

@k so flow's typeof is a flow operator that returns flow types. It only works in the flow domain, as in type declarations and annotations and so on. Javascripts typeof is an operator return strings with the name of the javascript type (more or less only 'string', 'number', 'boolean', 'object' or 'undefined').

So yes, they are completely different :-)

As for typeof "literal string" (flow's typeof), then I feel like that should also return the type "literal string". It would still be usable everywhere that a string type was expected, and it carries a lot more information

I dig Typescript's implementation making use of const.

+1

When defining reusable consts as module exports, code that needs to be refined still has to compare some variable explicit with string literal. It should be refined using === typeof someConst which doesn't work for now.