Repository navigation
Moving to TS 2.0 causes grief due to d.ts file incompatibility #10412
Description
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.
Activity
RyanCavanaugh commentedon Aug 18, 2016
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 commentedon Aug 18, 2016
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, andneveras types. The angular team has used a regexp to clean the new syntax from the declaration file.dbaeumer commentedon Aug 19, 2016
I think
null,undefined, andneveras 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 commentedon Aug 19, 2016
neveris sometimes inferred when unreachable code is noticed and leaks into.d.tsfiles. It is not opt-in only. I made a similar argument whenneverarose, 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 commentedon Aug 22, 2016
Kitson Kelly (@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 commentedon Aug 22, 2016
So major version of languages aren't allowed to introduce breaking changes? That seems like a severe limitation.
dbaeumer commentedon Aug 22, 2016
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 commentedon Aug 22, 2016
Notably, Java is often hamstrung by that decision (e.g. erased generics).
dbaeumer commentedon Aug 23, 2016
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 commentedon Sep 28, 2016
+1
christopherthielen commentedon Dec 15, 2016
I've started a simple regex-based tool that downlevels the .d.ts files generated for https://github.com/angular-ui/ui-router/ . It only downlevels the stuff that my own project is emitting, so feel free to submit PR.
https://github.com/christopherthielen/dts-downlevel