Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

5.6.0 breaks builds using TypeScript 3.5 #844

Closed
jshoemaker opened this issue Dec 4, 2019 · 5 comments
Closed

5.6.0 breaks builds using TypeScript 3.5 #844

jshoemaker opened this issue Dec 4, 2019 · 5 comments
Assignees
Labels
priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@jshoemaker
Copy link

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
Copy link

gae123 commented Dec 4, 2019

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
Copy link
Contributor

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.

@bcoe bcoe added type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. labels Dec 4, 2019
@gae123
Copy link

gae123 commented Dec 5, 2019

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
Copy link
Contributor

bcoe commented Dec 6, 2019

@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.

@bcoe bcoe closed this as completed Dec 6, 2019
@gae123
Copy link

gae123 commented Dec 6, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

No branches or pull requests

4 participants