Repository navigation
Invalid TS2339 Property '<prop>' does not exist on type 'never' in if/else branch #21517
Description
Activity
This is caused by #15256, where the
inexpression is now used as a type guard. the condition'setCustomValidity' in elementnarrows the type ofelementtoneverin the false branch, sinceHTMLInputElementis guaranteed to have asetCustomValidity.- addedBreaking ChangeWould introduce errors in existing codeWould introduce errors in existing code
on Jan 31, 2018 Right, but this check is for browser compatibility. The correct solution would be support that, or override this check locally?
I also have TS starts failing on my code:
isTouchDevice (): boolean { return !!('ontouchstart' in window) // works on most browsers || (window.navigator && window.navigator.msMaxTouchPoints > 0); // IE10 }with Error:(580, 36) TS2339: Property 'navigator' does not exist on type 'never'.
forwindow.navigatorSergei Dorogin (@evil-shrike) What is really needed is lib.ie.d.ts.
In my project I already started to write it with few IE only functions.
I think it is a good idea to create this definition and add it to TS or DefinitelyTyped.Sergei Dorogin (@evil-shrike) I opened a new repo for lib.ie: https://github.com/NN---/lib.ie.d.ts/ .
I am going to use it in my project first and push to DefinitelyTyped once it has enough content.That is not a viable solution. It would mean you would need a lib.d.ts for every browser combination.
Sebastiaan Dammann (@Sebazzz) I don't see why it is bad. In any case you need type definitions to be type safe.
Otherwise just use any.sandersn commented
on Feb 14, 2018 MemberMore actionsAfter some discussion in the typescript room, here are a couple of conclusions we reached.
1
The best solution is to use a workaround to avoid narrowing at all -- you don't really want narrowing behaviour here because (1)
elementdoesn't have a union type (2) you already know about the compatibility issue, so you don't need an error warning you about it. I suggestif ('setCustomValidity' in element as any)
2
This is technically a DOM bug, but not one that's feasible to fix. To be typesafe, the DOM types should be modelled as
IE6HtmlInputElement | IE7HtmlInputElement ... | Chrome44HtmlInputElement ...Each present-day type would become a union of hundreds of nearly identical types. This is the worst case for compiler performance and would be confusing to use as well. And it's a breaking change for anybody with strictNullChecks on.Alternatively,
setCustomValiditycould be made optional to reflect that it might or might not be present, but this too is a breaking change for those with strictNullChecks. This approach doesn't scale in the long-term, because all additions to the DOM would have to be optional. In 20 years we'd still be forced to check for the existence of properties that had been standard for decades.Sebazzz commented
on Feb 15, 2018 AuthorMore actionsThere is an additional option. What if the user could disable type narrowing per type, for instance in typing file. Met vriendelijke groet, Sebastiaan Dammann…________________________________ From: Nathan Shively-Sanders <notifications@github.com> Sent: Wednesday, February 14, 2018 7:25:31 PM To: Microsoft/TypeScript Cc: Sebastiaan Dammann; Mention Subject: Re: [Microsoft/TypeScript] Invalid TS2339 Property '<prop>' does not exist on type 'never' in if/else branch (#21517) After some discussion in the typescript room, here are a couple of conclusions we reached. 1 The best solution is to use a workaround to avoid narrowing at all -- you don't really want narrowing behaviour here because (1) element doesn't have a union type (2) you already know about the compatibility issue, so you don't need an error warning you about it. I suggest if ('setCustomValidity' in element as any) 2 This is technically a DOM bug, but not one that's feasible to fix. To be typesafe, the DOM types should be modelled as IE6HtmlInputElement | IE7HtmlInputElement ... | Chrome44HtmlInputElement ... Each present-day type would become a union of hundreds of nearly identical types. This is the worst case for compiler performance and would be confusing to use as well. And it's a breaking change for anybody with strictNullChecks on. Alternatively, setCustomValidity could be made optional to reflect that it might or might not be present, but this too is a breaking change for those with strictNullChecks. This approach doesn't scale in the long-term, because all additions to the DOM would have to be optional. In 20 years we'd still be forced to check for the existence of properties that had been standard for decades. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FTypeScript%2Fissues%2F21517%23issuecomment-365699236&data=02%7C01%7C%7Cd9193a60284f4374115108d573d855c3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636542295337057568&sdata=rljiZ%2BgTwPht2eKavxG4jpuSRBNJ9FLhoQ2s%2Fn%2BGKd4%3D&reserved=0>, or mute the thread<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABXCsZ4nxdeLk29s8fudnFfXV2ylILK9ks5tUyUVgaJpZM4R0sQA&data=02%7C01%7C%7Cd9193a60284f4374115108d573d855c3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636542295337057568&sdata=MrWvQinh7lTfbhzpyfg11IHUovXbtLSUvJVJ%2FwdjwGI%3D&reserved=0>.- locked and limited conversation to collaborators
on Jul 25, 2018
I think I may have found an issue in the newly released Typescript 2.7 release. I did not have this issue with Typescript 2.6.
TypeScript Version: 2.7.0
Search Terms:
TS2339
'never'
'classlist'
Code
Expected behavior:
No compilation error. In the if branch as shown in the compilation error,
elementwas never re-assigned to 'never'. Also, the branch is not impossible to execute which would otherwise trigger this error.Actual behavior:
Compilation error occurs:
TS2339: Property 'classList' does not exist on type 'never'Playground Link:
Text too large to share, so created Gist instead with full repro:
https://github.com/proxy/gist.github.com/Sebazzz/aaa19b9793ba80e34acd5e900a3e0c81
If you put both the .d.ts file and .ts file in the playground, the offending lines are highlighted however. For fully repro I did include the tsconfig but it does not appear to be relevant.