Cannot annotate a field in constructor as null using jsdoc @type
See original GitHub issueTypeScript Version: 4.0.2
Search Terms: jsdoc null type implicit any
Code
class Foo {
constructor () {
/** @type {number} */
this.bar = 42
/** @type {null} */
this.foo = null
}
}
Expected behavior:
Expected to have a class with two fields, bar of type number & foo of type null
I don’t know why it doesn’t understand null
; using string | null
works fine.
Actual behavior: Member ‘foo’ implicitly has an ‘any’ type.
Related Issues:
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (5 by maintainers)
Top Results From Across the Web
JSDoc Reference - TypeScript: Documentation
JSDoc Reference. The list below outlines which constructs are currently supported when using JSDoc annotations to provide type information in JavaScript files.
Read more >Use JSDoc: @type
Indicates that the value is of the specified type, but cannot be null . Variable number of that type, This function accepts a...
Read more >Joshua's Docs - JSDoc Cheatsheet and Type Safety Tricks
If you want to annotate the type of variables that are assigned via destructuring, it can be a little complicated with JSDoc.
Read more >Where is the syntax for TypeScript comments documented?
But you don't need to use the type annotation extensions in JSDoc. ... Note: you should not use JSDoc, as explained on TSDoc...
Read more >Type Checking JavaScript Files - TypeScript
Likewise, when types can't be inferred, they can be specified using JSDoc the ... annotate a declaration in the constructor with JSDoc to...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I can’t speak for the serializer code, since it’s much newer than getWidenedTypeForAssignmentDeclaration. However, the latter treats a lone
null
the same whether it comes from a type annotation or an initialiser – it’s regarded as an insufficient signal of intent and the code reports the error that @a-tarasyuk reports.The correct fix is to treat an explicit type annotation differently from a
null
initialiser. However, I can’t think of a good reason for declaring a property of typenull
. @Raynos can you explain what you were using it for? Until we have a good, commonly used reason, I don’t feel like improving these semantics.Meanwhile, I’m not sure what to do about the serialiser – it prioritises the type annotation for historical reasons. Ideally it should use the same rules as
getWidenedTypeForAssignmentDeclaration
, and one easy but expensive way to make that happen is to always request the actual type instead of short-circuiting on type annotation.This workflow is for converting an existing JavaScript class into a JSDoc --checkJS
// @ts-check
class.null
in the constructor but is then updated to be some concrete object in some asynchronous method further down in the classthis
field in the constructor so I can get explicit type checking@type {null}
is valid for the constructor to type check and remove the red errors.null
is a type error@type {null | MyThing}
I don’t need a
@type {null}
but its a useful temporary annotation to remove red errors linearly in my text editor /tsc
CLI as I’m going through a untyped file.