👍

I'm concerned that this creates .d.ts files that are non-backwards compatible with versions of tsc introduced before readonly support.

As an example, we had a class with some get-only accessors as part of a library we use internally, and we started compiling the library with typescript@next. This broke usage by internal applications that were still using the TS 1.8.x line, because they couldn't consume the new typings.

@jkillian would adding an empty setter to the source class be a problem?

@mhegazy That could be a good work around, or just changing the accessor to a regular method could work for us as well.

Really, just wanted to mention this because it was a surprising back-compat issue and I wasn't sure if it was intended or not.

Thanks @jkillian, this is not the first time we got this feedback, I will bring this up in the next design meeting.

Sounds good. I think this case would be solved nicely in a way similar to that mentioned here: that is, a "typingsTarget" option of some sort that lets you emit typings that will be compatible with older versions of the compiler. Of course, I don't know the complexity or difficulties of that, I'll happily work with whatever you all decide.

looping back, we are sorry we did not catch this issue as part of implementing the readonly properties. moving forward we will be more cognizant of adding new syntax to generated .d.ts files for new features.

it seems there is no clean solution for this issue, that does not involve yet another compiler flag. we would recommend either adding an empty setter or using a post build script to remove the reference to readonly for now. again sorry for the inconvenience, and we will add dts compat to our new feature checklist in the feature.