5.6.0 breaks builds using TypeScript 3.5

[jshoemaker]

5.6.0 changes typescript compiler from 3.6.0 to 3.7.0 and this generates type definition file that is not working with us who still use earlier versions.

node_modules/google-auth-library/build/src/auth/googleauth.d.ts(61,9): error TS1056: Accessors are only available when targeting ECMAScript 5 and higher. 

This appears to be the exact same issue that was reported for node-gtoken 3 weeks ago. googleapis/node-gtoken#244

Environment details

• Node.js version: 8.16.2
• npm version: 6.4.1
• google-auth-library version: 5.6.0
• Typescript version: 3.5.3

[gae123]

This hits us too.

This is an epidemic with the Google libraries. It seems that every other day a library breaks our build with this same issue.

Do you Googlers have some common way to let everybody else in the company know not to make the same mistake?

You are also in the business of shipping "libraries", don't you realize you need to test your packages with code built with previous versions of the compiler?

[JustinBeckwith]

Greetings folks, and thanks for the heads up. When something does break for you - we love it when folks file issues, and we try to get to them in a timely fashion.

In terms of "making the same mistake" - we generally snap to the latest available version of TypeScript for our libraries. Due to the way the TypeScript compiler makes backwards
incompatible changes in semver minor releases. With this particular change - the code emitted by 3.7 is backwards compatible with 3.6, but not 3.5 🤦‍♂

This puts us in a position where we have no way to know when it's acceptable to accept a new version of the compiler. I see a few options, and I'm curious where folks stand:

1. We make semver minor updates to the TypeScript compiler a semver major change in the module. This is very heavy handed, but feels like the only way we could guarantee updates won't break downstream users. It's unfortunate because it would increase the number of semver major releases, when there are likely no runtime changes.

2. We institute a "latest version only" policy of the TypeScript compiler, and document it. This is essentially where we are today, and does come with the risk of breaking people when the TypeScript compiler changes. But at least then we wrote it down, and y'all know what to expect.

I am hoping @bcoe or @alexander-fenster have other ideas 😆

Regardless of where we go here - we need to have a strategy, write it down, and make sure folks know where we're headed.

On this note:

You are also in the business of shipping "libraries", don't you realize you need to test your packages with code built with previous versions of the compiler?

I can understand that you're frustrated, but we're all humans here. I'd appreciate a little more assumption of best intent. I'm happy to have a discussion about the policies of how we support older versions of the TypeScript compiler, or how we test it - but please let's try to do so in a kind way.

[gae123]

Listen, I think you need to show some patience in embracing the latest typescript version. Start with using tests compiled with previous versions of typescript (ie what we do) against your libraries that are compiled with whatever version of TS you want, and document what is the earliest version of TS you support because of issues like this. But you need to give developers 6-12 months to move and when you hit issues like that you need to back out before we point it out to you.

I also want to be at the latest TS but here are my constraints. I currently work on a project that has both back end and front end in typescript. Front end uses angular and there is some shared code between front end and back end, and since we are full stack developers and try to keep our sanity, the TS version supported by angular is the LCD. We just switched to angular 8 that supports "typescript": "~3.5.3"; angular 9 is in RC with "typescript": "~3.6.4",. We will move to angular 9 when we feel it is stable and we get an upgrade window.

Is Microsoft aware of the issue they introduced with this incompatibility? Was it on purpose (ie release noted), or it was an oversight on their part? Is there an issue filed in the latter case with the typescript project?

[bcoe]

@jshoemaker this issue should have been addressed by #845.

We have opted to pin TypeScript for the time being across the ~80 libraries we manage, until we can figure out a better resolution for the upstream TypeScript issue.

---

We are also working on adding support for multiple TypeScript versions to our tool pack-n-play which is used to smoke-test our TypeScript libraries.

Note: it will take another day or so to get all 80 libraries updated.

[gae123]

@bcoe I confirm that I removed the workarounds in our package.json files and we do not see the issue any more, thanks to you and @JustinBeckwith for the quick resolution.

Thanks for pointing to the upstream TS issue.