Repository navigation
Moving to TS 2.0 causes grief due to d.ts file incompatibility #10412
Description
Activity
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.
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.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.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.
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.
So major version of languages aren't allowed to introduce breaking changes? That seems like a severe limitation.
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.
Notably, Java is often hamstrung by that decision (e.g. erased generics).
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.
+1
Someone can write a downleveler tool if it's truly needed - it'd be quite simple.
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.
- locked and limited conversation to collaborators
on Jun 19, 2018
TypeScript Version: 1.8.x and 2.0
Code
A d.ts file for this ts file looks with 2.0 like this:
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.