3.7.4 emits d.ts files incompatible as inputs to programs with noImplicitAny or strict flags

[IgorMinar]

TypeScript Version: 3.7.4

Search Terms:
noImplicitAny, strict, d.ts, declaration, getter, get, private

Code

class PrivateClass {}

export class ExportedClass {
  private get _privateRef(): PrivateClass { return new PrivateClass() }
}

tsconfig.json

{
  "compilerOptions": {
    "strict": true,
    "rootDir": ".",
    "target": "es5",
    "types": [],
    "declaration": true
  }
}

Expected behavior:

produces d.ts which if compiled against in a program with strict mode on is compiled successfully, for example (note _privateRef(): any):

export declare class ExportedClass {
  private get _privateRef(): any;
}

Actual behavior:
get _privateRef() is emitted without any explicit type and is implicitly set to any which triggers compilation failure:

export declare class ExportedClass {
  private get _privateRef();
}

resulting in:

error TS7033: Property '_privateRef' implicitly has type 'any', because its get accessor lacks a return type annotation.

1 export declare class ExportedClass { private get _privateRef(); }

Playground Link:

Related Issues:

[IgorMinar]

Real world d.ts file that fails to compile: https://unpkg.com/browse/@angular/compiler@9.0.0-rc.9/src/output/abstract_emitter.d.ts#L23

You can test it by compiling a simple program:

setup:

yarn add @angular/compiler@9.0.0-rc.9

program:

import * as test from '@angular/compiler';
export default { test };

[RyanCavanaugh]

Ugh, this is awkward. We shouldn't have ever complained about the missing : any type annotation, and in fact we should disallow type annotations here at all -- private fields in .d.ts files just shouldn't have type annotations.

I am inclined to make a 3.7.6 to prevent this from turning into a long-term compat annoyance. Would that be sufficient for your setup?

[RyanCavanaugh]

cc @sandersn in case he has any thoughts

[filipesilva]

I think it would be sufficient for our setup, yes.

If doing a 3.7.6, we could also use #36098 since it affects other parts of our setup.

[ajafff]

This should already be fixed with #33896 which according to the tags is included in v3.7.4

[filipesilva]

@ajafff I think your fix addresses the problem for consumers on 3.7.4, is that correct?

In our case we have typings created with 3.7.4 that we also wish to be consumed by users on 3.6.

[ajafff]

@filipesilva you are right. My PR removes this restriction from 3.7.4, it doesn't change the emitted declarations.

In our case we have typings created with 3.7.4 that we also wish to be consumed by users on 3.6.

So this is a duplicate of #36207 (and many more). The proposed solution is to use https://www.npmjs.com/package/downlevel-dts. This tool could probably add an explicit : any return type for get accessors when tareting 3.6.

[IgorMinar]

I am inclined to make a 3.7.6 to prevent this from turning into a long-term compat annoyance. Would that be sufficient for your setup?

@RyanCavanaugh yes

[DanielRosenwasser]

So what's the new behavior? Always emit these with an unknown and/or any? Does 3.7.6 also not consider this a noImplicitAny error?

[DanielRosenwasser]

We could also make 3.6 not error on this instead because I think it's the only version that actually recognizes getters in a .d.ts

[DanielRosenwasser]

We're going to do the latter. Users who run into issues will be able to upgrade to 3.6.5 from ≤3.6.4.

[DanielRosenwasser]

3.6.5 should be available now. Thanks for the the heads up on all this!

[DanielRosenwasser]

In case we can help confused users https://stackoverflow.com/questions/59886814/why-do-i-get-an-implicit-any-error-on-a-private-getter-in-my-d-ts-files/59886845#59886845