Unexpected TS4094 with the build parameter `declaration: true`

[saschanaz]

TypeScript Version: 2.4.1

Code

var Foo = class Foo {
    private _message = "Hi";
    hi() { return this._message; }
}

tsc test.ts -t es2017 -d

Expected behavior: -d should not cause this message: test.ts(1,5): error TS4094: Property '_message' of exported class expression may not be private or protected.

Actual behavior: It does.

There should at least be a suppression parameter to ignore this error.

[tusharmath]

I am facing the same issue.

[yeliex]

any progress? @weswigham

[weswigham]

Like many of our still-open declaration emit issues, fixing this would require significant changes to our declaration emit. Today, we'll try to emit the example in the OP as:

declare var Foo: {
  new (): {
    // Try to write type for `_message` here
    hi(): string;
  }
}

except since we're in an anonymous object literal type, there is no way to write a private or protected member, so instead we write a visibility error and refuse to generate declarations. The only "correct" thing to do to fix this is to generate an interface for Foo's instance type, that way member modifiers can be preserved. The issue with that is that generating an interface would change the publicly visible declarations for your file (namely, it would introduce one you never actually wrote, but was implicit in the usage of a class expression).

For now, the workaround is to explicitly give a type to your var Foo = /* ... */, ie var Foo: {new(): IFoo} = /* ... */, where you've defined IFoo.

The reason this issue and others like it (issues assigned to me in the category of declaration emit which I have not already created fixes for) are sitting for so long is because we're in the process of overhauling our declaration emitter to make it easier to generate things like these implicit interfaces (or imports, dependent variables, etc) without changing the public shape of your declaration file, and it's a long process to do the refactoring (generally speaking, big changes are difficult to review, and this is a series of big changes). We are replacing a 3-yr-old subsystem that contains >2000 LOC, countless edge-cases and deep connections to the type checker and emitter, after all. ;)

We are working on it, though. While I can't make any promises for this specific issue, we're hoping to have the prerequisite changes we want to make to make this possible done in the 2.7 timeframe.

[weswigham]

@mhegazy The fix for this issue (and #17744) seem predicated on that idea that we could hoist these class expressions to a private name within a module and the reference them in the type definitions elsewhere. While this can work well inside modules or namespaces, in the global scope (like the example in the OP here), there's no way to do that hoisting without introducing a name that doesn't actually exist into the global scope (which is dangerous from an API perspective). Maybe we should consider a different approach? (anonymous class type nodes?)