Cannot use a class with private fields as an interface for object literal

[danielmoore]

TypeScript Version: 2.2.0-dev.20161212

Code

class Foo {
  constructor(private secret: number){}
  bar() { return 1; }
  baz() { return 2; }
}

const mock: Foo = {
  bar() { return 2; },
  baz() { return 3; },
}

Expected behavior:

Code compiles with no issue.

Actual behavior:

mocks.ts(7,7): error TS2322: Type '{ bar(): number; baz(): number; }' is not assignable to type 'Foo'.
  Property 'secret' is missing in type '{ bar(): number; baz(): number; }'.

Comments:

Intriguingly, there is no way to use Foo as an interface without coercing it through any (afaict). I think the "classes are interfaces" aspect of TypeScript is incredibly powerful, but this behavior ruins it.

[RyanCavanaugh]

Because Foo instances can see other Foo instance's privates, it's not safe to provide a mocked Foo which lacks private members (see #10516). You can use a type assertion in this case if you want the code to proceed anyway.

[danielmoore]

Ok, then it should be legal to do:

const mock: Foo = {
  secret: 42,
  bar() { return 2; },
  baz() { return 3; },
}

but that causes:

mocks.ts(7,7): error TS2322: Type '{ secret: number; bar(): number; baz(): number; }' is not assignable to type 'Foo'.
  Property 'secret' is private in type 'Foo' but not in type '{ secret: number; bar(): number; baz(): number; }'.

There should be some way of implementing that interface with an object literal.

[RyanCavanaugh]

Again, you'll need a type assertion here. The issue in this case is that a private definition must originate from the same declaration (otherwise you could alias your mock into disparate Foo and Bar classes and create separate meanings for secret).

[danielmoore]

I would argue the whole point of structural typing is that you can do just that- if the shape fits, it should work.

More to the point, I feel like you're guarding against a case that hardly arises in real practice, but precludes basic testing practices that have been going on in the JS community since forever.

As for the type assertion, it's rather unfortunate that I have to disable all type checking, especially when type checking is what I want in my test. I want to be certain that my mocks uphold the shape of objects my systems under test expect. Of course, I can extract the "header interface" and have the class and mock implement that (as one does in Java/C#), but that seems rather to defeat the point that classes are interfaces.