Typescript: TS 3.7: --declaration output for getter only property now is a getter instead of `readonly`

[mjbvz]

TypeScript Version: 3.7.0-dev.20191010

Search Terms:

• --declaration
• getter
• d.ts

Repo:
For the TS file foo.ts:

export class Foo {
    get bar(): boolean { return true; }
}

1. Run tsc foo.ts --declaration

Expected
In TS 3.6, the output d.ts uses readonly:

export declare class Foo {
    readonly bar: boolean;
}

Actual behavior:
In TS 3.7, the output d.ts use a getter instead:

export declare class Foo {
    get bar(): boolean;
}

[Jessidhia]

That is an intentional change done as part of https://github.com/microsoft/TypeScript/issues/27644 that, it seems, was missed from the 3.7 blog post.

See also https://github.com/microsoft/TypeScript/pull/33509 and https://github.com/microsoft/TypeScript/pull/33880

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[AndreasGassmann]

I just noticed this as well. The problem is that when I use our own library with the "getter-syntax", I get an error:

error TS1086: An accessor cannot be declared in an ambient context.

What is the recommended way of getting around that?

[matthiasg]

I have the same issue with 3.7 .. importing the types is now not possible

[AndreasGassmann]

@matthiasg It seems that they knew the typings were incompatible. I'm quite surprised that there was no mention of this anywhere (or did I overlook it?). https://github.com/microsoft/TypeScript/pull/33470

I ended up writing a small script for our CI that replaces the new syntax with the old one as a temporary solution.

[GordonSmith]

This will prevent my library from upgrading to 3.7.x until all my customers are also using 3.7.x (and they include Angular folks who won't be upgrading Angular anytime soon).
Given this is a breaking change shouldn't it have waited until 4.x.x?

[paulquinn]

I'm also getting TS1086 when trying to use npm libraries with the "getter syntax" - could someone please give some guidance around this/can this be reopended?

[bcoe]

This seems like a fairly significant breaking change, and is biting a lot of our customer:

https://github.com/googleapis/node-gtoken/issues/244

I understand it's working as intended, but I question why this was released in a minor release of the library, vs., a 4.x release like @GordonSmith mentions.

[paulquinn]

@RyanCavanaugh is there any other any guidance here (other than re-target to 3.6 or lower)? At least this should be documented somewhere... this is blocking up from using libraries compiled with 3.7 with our current Angular projects.

[endel]

Also having the same issue in an Angular project.

[bcrosnier]

Also got bit by the sudden breaking change through an Angular project (TS 3.5) referencing a library built by 3.7 with breaking definitions.

Solved by bashing the library provider until he rolled back to TS 3.6.

Just for reference, TS 3.7 support in Angular projects is handled by https://github.com/angular/angular-cli/issues/16071.

[kamilmysliwiec]

Why is this issue closed? This PR should be reverted as soon as possible due to the breaking change it introduced. I can't update TS to 3.7+ in NestJS as well because people with TS 3.7 < won't be able to use it (see https://github.com/nestjs/nest/issues/3513). The only existing solution is to downgrade TypeScript and don't use the latest version.

[robinsummerhill]

Why is this issue closed? This PR should be reverted as soon as possible due to the breaking change it introduced. I can't update TS to 3.7+ in NestJS as well because people with TS 3.7 < won't be able to use it (see nestjs/nest#3513). The only existing solution is to downgrade TypeScript and don't use the latest version.

I agree. This issue is causing major headaches throughout the library vendor community. The change should be opt-in and maybe tied to the new useDefineForClassFields option. Claiming that this is 'working as intended' does not help the library vendors that are now stuck on 3.6 because of this issue. I suspect that this side-effect was not planned and slipped through.

[gms1]

@RyanCavanaugh
please do not intend to introduce any breaking changes in minor versions

[tdillon]

Solution/workaround for the foreseeable future:

"typescript": "3.6.x"

[RyanCavanaugh]

https://github.com/sandersn/downlevel-dts

[GordonSmith]

@RyanCavanaugh FWIW those instructions don't "just work" (and had to give up).

[RyanCavanaugh]

It's a work in progress; you should see more polish here in the coming weeks

[GordonSmith]

@RyanCavanaugh While I have you attention there is a vaguely related issue/question - a big disjoint I see between types and generated JS in my npm package.json:

• dependencies
• devDependencies

In my (hypothetical) project I have a devDependency on "d3" as I use rollup to create a single lib for reuse in other projects.

One of my classes exports a method that returns a TYPE from @types/d3 (which has been auto resolved via typescript).

Now if I publish my package to npmjs my customers will get errors as they won't have any reference to the types... (@types/d3)

I think the solution is to have the ability to bundle types via rollup in the same way I bundle the JS?

If that is the correct solution - then (for me) the best pace to have downlevel-dts support would be as a rollup-js plugin?

[octogonz]

Here's a proposal to enable newer compilers to emit backwards-compatible output: https://github.com/microsoft/TypeScript/issues/36207

It's NOT proposing a complete set of transforms that lower new constructs to equivalent older syntaxes.

Instead, it's merely an option to ensure that _backwards-compatible source code produces backwards-compatible .d.ts files_.

[rabomarnix]

We (library developers) should not be using downgrading tools because of a breaking change in a minor typescript version; This change is not versioned as intended.

[octogonz]

@rabomarnix FYI issue https://github.com/microsoft/TypeScript/issues/36207 is still open and asking for "strong evidence".

[Gluups]

Pardon me if I did not assimilate the whole thread properly, but I saw the error message "An accessor cannot be declared in an ambient context" appeared when migrating from TS 3.6 to TS 3.7
Just after typing NPM UPDATE, I see that "tsc -v" answers "Version 3.1.2", and I still get that error message.
What version do you recommend me to downgrade to, and is there any direct way to do that or must I uninstall the product and reinstall it with a version number given ?
Or do you think the problem can be situated elsewhere ?
Angular CLI: 9.1.5
Node: 10.15.0
OS: win32 x64

Angular:
...
Ivy Workspace:

Package Version

@angular-devkit/architect 0.901.5
@angular-devkit/core 9.1.5
@angular-devkit/schematics 9.1.5
@schematics/angular 9.1.5
@schematics/update 0.901.5
rxjs 6.5.4

[Gluups]

Pardon me if I did not assimilate the whole thread properly, but I saw the error message "An accessor cannot be declared in an ambient context" appeared when migrating from TS 3.6 to TS 3.7
Just after typing NPM UPDATE, I see that "tsc -v" answers "Version 3.1.2", and I still get that error message.
What version do you recommend me to downgrade to, and is there any direct way to do that or must I uninstall the product and reinstall it with a version number given ?
Or do you think the problem can be situated elsewhere ?
Angular CLI: 9.1.5
Node: 10.15.0
OS: win32 x64

Angular:
...
Ivy Workspace:

Package Version

@angular-devkit/architect 0.901.5
@angular-devkit/core 9.1.5
@angular-devkit/schematics 9.1.5
@schematics/angular 9.1.5
@schematics/update 0.901.5
rxjs 6.5.4

First, I read a bad information on Stackoverflow : tsc - v will not give you the version of TypeScript used in an Angular project, rather ask "ng version".
Well, I downgraded a few products, but still get "an accessor cannot be declared in an ambient context".
To downgrade, edit the version numbers in package.json, then close any tool that may be opened on the project including Visual Studio, and type "npm install".
Maybe I missed one ?
"@angular/cli": "~6.0.0", "@angular/compiler-cli": "~6.0.0", "ts-node": "~3.5.0", "typescript": "~3.5.0"

[rabomarnix]

@Gluups Don't think it's relevant to this issue, but you probably have [email protected] installed globally on your system. What version do you see if you do npx tsc -v?
You should either remove typescript globally or update it using npm i [email protected] -g or use npx tsc .. to grab your local typescript version.

If you still experience the error an accessor cannot be declared in an ambient context, then you have one or more dependencies which were released using typescript 3.7.. That's exactly the issue people are running into now.

[Gluups]

"npx tsc -v" tells me "3.5.3"
I have launched "npm i [email protected] -g" (it was quicker than I thought).
The number of errors has decreased to 148 when I launch the execution from Visual Studio, but I am afraid I still get the error "Impossible to declare an accessor in an ambient context".

package.json :
{
"name": "weather-client",
"version": "0.0.0",
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e"
},
"private": true,
"dependencies": {
"@angular/animations": "~9.1.6",
"@angular/common": "~9.1.6",
"@angular/compiler": "~9.1.6",
"@angular/core": "~9.1.6",
"@angular/forms": "~9.1.6",
"@angular/platform-browser": "~9.1.6",
"@angular/platform-browser-dynamic": "~9.1.6",
"@angular/router": "~9.1.6",
"rxjs": "~6.5.4",
"tslib": "^1.10.0",
"zone.js": "~0.10.2"
},
"devDependencies": {
"@angular-devkit/build-angular": "~0.901.5",
"@angular/cli": "~6.0.0",
"@angular/compiler-cli": "~6.0.0",
"@types/node": "^12.11.1",
"@types/jasmine": "~3.5.0",
"@types/jasminewd2": "~2.0.3",
"codelyzer": "^5.1.2",
"jasmine-core": "~3.5.0",
"jasmine-spec-reporter": "~4.2.1",
"karma": "~5.0.0",
"karma-chrome-launcher": "~3.1.0",
"karma-coverage-istanbul-reporter": "~2.1.0",
"karma-jasmine": "~3.0.1",
"karma-jasmine-html-reporter": "^1.4.2",
"protractor": "~5.4.3",
"ts-node": "~3.5.0",
"tslint": "~6.1.0",
"typescript": "~3.5.0"
}
}

---

ng version :
@angular-devkit/architect 0.901.6
@angular-devkit/build-angular 0.901.6
@angular-devkit/build-optimizer 0.901.6
@angular-devkit/build-webpack 0.901.6
@angular-devkit/core 9.1.6
@angular-devkit/schematics 0.6.8
@angular/cli 6.0.8
@angular/compiler-cli 6.0.9
@ngtools/webpack 9.1.6
@schematics/angular 0.6.8
@schematics/update 0.6.8
rxjs 6.5.5
typescript 3.5.3
webpack 4.42.0

[Gluups]

If you still experience the error an accessor cannot be declared in an ambient context, then you have one or more dependencies which were released using typescript 3.7.. That's exactly the issue people are running into now.

Hum, that promises to be an adventure, does not it ? Anyway thank you for your answer.

[rabomarnix]

This is why typescript 3.7 does not produce not backwards-compatible typings imo. You need to upgrade to typescript 3.7 and the latest version of angular 9 which will work in your case I guess.

[Gluups]

I realize something. As the project already has worked properly, one reasonable solution is to restore package.json from the backup, and then run "npm install" -and surely not "npm update".
Supposing that when groping around to solve those errors you did not practice too many foolishnesses, that should work pretty quickly.
As a conclusion of this, if you have a source control, pay attention to include package.json in it.

Well, in the project there are some dependencies marked deprecated and others marked vulnerable, but this is another story -that can lead me back here of course.

[Driez]

i guess breaking changes in minor versions are a new trend, are they now? Good job typescript team.... please get your stuff together and make stuff like this a major version upgrade next time....