Moving to TS 2.0 causes grief due to d.ts file incompatibility

[dbaeumer]

TypeScript Version: 1.8.x and 2.0
Code

export class A {
    get value(): number {
        return 10;
    }
}

A d.ts file for this ts file looks with 2.0 like this:

export declare class A {
    readonly value: number;
}

This d.ts file can't be consumed by clients still using 1.8.10 compiler. To ease transition to 2.0 the compiler should allow to generate 1.8 compliant d.ts file if possible, which is not possible for example with using undefined as a type.

[RyanCavanaugh]

This would be at the expense of accuracy for other 2.0 users. We don't guarantee downlevel .d.ts emit and never have. Someone can write a downleveler tool if it's truly needed - it'd be quite simple.

[mhegazy]

please see my comment in #6702 (comment) and in #7573.

This is an unfortunate side effect of the type system getting more accurate. this also applies to null, undefined, and never as types. The angular team has used a regexp to clean the new syntax from the declaration file.

[dbaeumer]

I think null, undefined, and never as types fall into a different category since there I actively decided to use them in my code as types, hence they have to be in the .d.ts, I still think not having this backwards compatibility will cause more grief and work for the TS team since we have to teach people about the work arounds.

[kitsonk]

never is sometimes inferred when unreachable code is noticed and leaks into .d.ts files. It is not opt-in only. I made a similar argument when never arose, because of its non-opt in nature, but Ryan's comment was valid, that basically every major release of TypeScript have breaking changes that affect previous versions of TypeScript.

I think in particular, TypeScript 2.0 would be a significant flag to people that there are likely to be breaking changes.

[dbaeumer]

@kitsonk but this has a very bad ripple. If I write an npm module and now upgrade to TS 2.0 I am almost forced to do a major version number change of my npm module since I force all users of my npm module that use TS to upgrade as well. And they might not be able to. So I need to give them a choice.

From my experience having backwards compatibility in a language is very critical for adopting new versions.

[kitsonk]

So major version of languages aren't allowed to introduce breaking changes? That seems like a severe limitation.

[dbaeumer]

They are for new features. However if I use my code unchanged it would be cool if they can generate code that is compatible. Java for example did this for the generated byte code.

[RyanCavanaugh]

Notably, Java is often hamstrung by that decision (e.g. erased generics).

[dbaeumer]

As said I am not arguing against new features (like generics, undefined, never type, ....). I am only saying that if my code successfully compiles with 1.8.10 I should be able to generate the same output with 2.0.

[dzearing]

+1