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

Fix TS 4.0 breaks #10415

Closed
wants to merge 2 commits into from
Closed

Fix TS 4.0 breaks #10415

wants to merge 2 commits into from

Conversation

sandersn
Copy link

@sandersn sandersn commented Aug 3, 2020

  1. Pass undefined to now-required parameters of typeToTypeNode.
  2. Fix new error "operand of delete must be optional".

Typescript 4.0 only allows deletion of properties that are marked as optional. This allows control flow to narrow the type after deletion to undefined, preventing use-after-delete:

declare var o: { p?: number }
o.p // p: number | undefined

o.p = 12
o.p // p: number
o.p++ // OK

delete o.p
o.p // p: undefined
o.p++ // ERROR

Unfortunately, for this to work, the property must include undefined in its type. Currently, this PR doesn't actually make properties optional. It just casts the object operand to any, which silences the error. Please use this PR as a starting point for an actual fix, which may end up pretty complex.

Fixes #10414, although casting to any is not a good long-term fix for problem (2).
Edit: I just noticed that all the deletes happen in tests, to eliminate unique ids before testing equality, so probably casting to any is good enough.

This PR does not upgrade azure-sdk to TS 4.0. We'll have to manually upgrade the repo to 4.0 to test this. I can provide the instructions I used if needed, although they're pretty hacky.

1. Pass `undefined` to now-required parameters of typeToTypeNode.
2. Fix new error "operand of `delete` must be optional".

Typescript 4.0 only allows deletion of properties that are marked as
optional. This allows control flow to narrow the type after deletion to
`undefined`, preventing use-after-delete:

```ts
declare var o: { p?: number }
o.p // p: number | undefined

o.p = 12
o.p // p: number
o.p++ // OK

delete o.p
o.p // p: undefined
o.p++ // ERROR
```

Unfortunately, for this to work, the property must include `undefined` in
its type. Currently, this PR doesn't actually make properties optional.
It just casts the object operand to `any`, which silences the error.
Please use this PR as a starting point for an actual fix, which may end
up pretty complex.

Fixes Azure#10414, although casting to `any` is *not* a good long-term fix
for problem (2).
@sandersn
Copy link
Author

sandersn commented Aug 3, 2020

@xirzec you will probably be interested in this, according to @bterlson

@sandersn
Copy link
Author

sandersn commented Aug 3, 2020

The CI log lists @azure/ai-form-recognizer as the failing test suite, but I can't find the actual failure.

@mikeharder
Copy link
Member

The CI log lists @azure/ai-form-recognizer as the failing test suite, but I can't find the actual failure.

If you are referring to the Mac-only test failure, it was probably a flaky test. I triggered a re-run of the Mac tests.

Copy link
Member

@mikeharder mikeharder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sandersn: Thanks for testing our repo with TS 4.0 and submitting this PR.

I defer to @xirzec regarding the code changes.

In terms of process, my preference would be to keep this PR open until we are ready to actually upgrade to TS 4.0, and include the upgrade to TS 4.0 in the PR itself (as opposed to merging this now and upgrading to TS 4.0 later). So we could add the changes to upgrade to TS 4.0.0-beta in this PR right now, then update to 4.0.0-rc and finally 4.0.0, each time ensuring the CI builds pass. And if we find additional changes required for 4.0 we can collect them in this PR.

@xirzec
Copy link
Member

xirzec commented Aug 3, 2020

The type checker change seems reasonable to me, though /cc @willmtemple for visibility.

The test change I'm okay with as-is, though we could also consider figuring out a better way to write these tests. requestId was added after the tests were written and introduced uniqueness to request instances that got in the way of simple deep equal test checks.

I'm not very motivated to spend a lot of time on core-http tests though, since I'd rather spend that energy moving us over to core-https.

Copy link
Member

@xirzec xirzec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving this, to get ahead of adopting 4.0 after this release train.

@deyaaeldeen
Copy link
Member

deyaaeldeen commented Dec 15, 2020

Thanks @sandersn for taking the initiative here! We just upgraded to version 4.1.2 here #12770
EDIT: initially linked to wrong PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

azure-sdk fails to build on Typescript 4.0
4 participants