Non-Nullable Objects in params don't have properties parsed

[zavr-1]

TypeScript Version: 3.5.2

Search Terms: object param

Code

/**
 * Converts a type to a markdown string.
 * @param {!Object} [opts]
 * @param {boolean} [opts.narrow] Combine type and description.
*/

Expected behavior:

Actual behavior:

Playground Link:

Related Issues:

[sandersn]

The parser only supports the following markers for nested type construction: object, Object, object[], Object[] — it's too error-prone to support any type containing Object as a marker. No documentation for jsdoc or closure mention support for !Object either, although it's possible that closure does support it.

[zavr-1]

@sandersn i know the parser doesn't support it that's why the issue is there. what do you mean error-prone? you can't add ! lookup in the parser? !Object is just same as Object which cannot be null. if anything, your parser is incorrect NOW because null is not destructurable. why close issue.

[sandersn]

1. Object is a syntactic marker in this construction, not a real type.
2. No other systems support !Object in this construction as far as I know -- please do point out ones that do.
3. I don't want Typescript to be the only system to support this construction because I don't want to encourage new code to be written with this construction. It's only for understanding existing code that was written for closure or jsdoc generation.

New code should use multiple typedefs, Typescript's own object literal types, or just declare types in a separate d.ts file.

[zavr-1]

@sandersn thanks for the reply mate. i understand this post is in typescript repo but it's not about typescript but vscode, as all issues like that are moved in here.
i failed to describe that, yes closure does support it. the sole bug is here because I can't use closure properly. you can have a primitive object in closure like { abc: string } or you can have a record. a record is nullable, whereas primitive is not. therefore when passing records as arguments, i have to mark them as non-null with ! because otherwise the compiler gives me a warning. see here https://github.com/google/closure-compiler/wiki/Types-in-the-Closure-Type-System
Non-nullable type

[sandersn]

This is the right place for JS-in-VSCode bugs, since TS handles those too.

I tried an example program on the Closure Compiler Service and it gave me this warning:

JSC_INVALID_PARAM: Parse error. invalid param name "name.narrow" at line 3 character 20
 * @param {boolean} [name.narrow]

If I changed the actual properties to something else, like now, but left the JSDoc with narrow, the error doesn't change. That indicates to me that Closure is ignoring the JSDoc.

Did I do something wrong? Does that version of Closure not support nested object types? I pasted the full program below in case the link doesn't work.

// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// @output_file_name default.js
// ==/ClosureCompiler==

/**
 * @param {!Object} [name]
 * @param {boolean} [name.narrow]
 */
function hello(name) {
  if (name)
    alert(name.narrow);
}
hello({ narrow: true });

[zavr-1]

yeah i don't know which version they are running on their gcc apps but there's no warning on the current standalone (google-closure-compiler-java) JAR.

[gabritto]

I ran into a similar issue when working on #52370. The issue I found is that using destructuring in @param annotations doesn't work if you don't have the type annotation:

/**
 * 
 * @param {Object} param0 description
 * @param {*} [param0.a=1] some desc
 */
function foo({ a = 1 }) { } // This works, we understand "some desc" is a description for `a`

/**
 * 
 * @param param0 description
 * @param [param0.a=1] some desc
 */
function bar({ a = 1 }) { } // This doesn't work, we don't understand "some desc" is a description for `a`

Looking at the parser code with Nathan, this seems to be because we only speculatively try to parse the following @param (or @property) JSDoc tags as child tags if the current tag has a type expression that is either Object or Object[] (and object variants). So you can't omit the type annotation for this kind of destructured annotation to work, which is something you probably want to do if you're annotating something in TypeScript, since then the type annotations will be irrelevant and the linter might complain about them. This is similar to what was reported above originally, but there the problem is that the type expression doesn't match Object or Object[].