* Include export assignment properties when looking for module exports
* Create new API function for tryGetMemberInModuleExportsAndProperties
* Cleanup based on review feedback
* Add 'name' property to Identifier
* Rename to unescapedText
* Rename 'id.text' to 'id.escapedText'
* Rename 'id.unescapedText' to 'id.text'
* Make escapeIdentifier and unescapeIdentifier do nothing
Now Typescript supports the creation of anonymous types using successive
`@param` lines in JSDoc:
```js
/**
* @param {object} o - has a string and a number
* @param {string} o.s - the string
* @param {number} o.n - the number
*/
function f(o) { return o.s.length + o.n; }
```
This is equivalent to the Typescript syntax `{ s: string, n: number }`,
but it allows per-property documentation, even for types that only need
to be used in one place. (`@typedef` can be used for reusable types.)
If the type of the initial `@param` is `{object[]}`, then the resulting
type is an array of the specified anonymous type:
```js
/**
* @param {Object[]} os - has a string and a number
* @param {string} os[].s - the string
* @param {number} os[].n - the number
*/
function f(os) { return os[0].s; }
```
Finally, nested anonymous types can be created by nesting the pattern:
```js
/**
* @param {Object[]} os - has a string and a number
* @param {string} os[].s - the string
* @param {object} os[].nested - it's nested because of the object type
* @param {number} os[].nested.length - it's a number
*/
function f(os) { return os[0].nested.length; }
```
Implementation notes:
1. I refactored JSDocParameterTag and JSDocPropertyTag to
JSDocPropertyLikeTag and modified its parsing to be more succinct. These
changes make the overall change easier to read but are not strictly
required.
2. parseJSDocEntityName accepts postfix[] as in `os[].nested.length`,
but it doesn't check that usages are correct. Such checking would be
easy to add but tedious and low-value.
3. `@typedef` doesn't support nested `@property` tags, but does support
`object[]` types. This is mostly a practical decision, backed up by the
fact that usejsdoc.org doesn't document nested types for `@typedef`.
- We didn't locate the package.json correctly in cases where the module to be imported is in a subdirectory of the package
- We didn't look at the types element in package.json (just typings)
- We didn't remove /index.js from the path if the main module was in a subdirectory
Fixes#16963
Instead of trying to walk the type structure in the codefix, I changed
to call getTypeFromTypeNode in the checker and then calling
typeToString. Together, these two functions normalise out JSDoc.
Note that you only get `T | null` for `?T` if you have --strict on. This
is technically correct -- adding a null union does nothing without
strict -- but it would still serve as documentation.
For ?, provide two code fixes, one for jsdoc/closure semantics
(`?t -> t | null)` and one for flow semantics
(`?t -> t | null | undefined`).
The current way of doing this is the hackiest thing you can imagine, but
it was easier than lifting everything into the list monad for a code fix
that I might not actually keep.
1. Still pretty janky.
2. Type Reference code doesn't work yet.
3. Other transforms just aren't done.
4. Always replaces, even when there isn't any transformation of JSDoc
types. (This probably isn't an issue since we wouldn't issue an error unless there were
some JSDoc to change.)
This means that JSDoc types can include the full range of Typescript
types now. It also means that Typescript annotations can include JSDoc
types. This is disallowed with a new error, however. But Typescript can
still give the correct types to JSDoc that shows up in .ts files by
mistake. This can easily happen, for example with types like
```ts
var x: number? = null;
var y: ?string = null;
var z: function(string,string): string = (s,t) => s + t;
// less likely to show up, but still understood.
var ka: ? = 1;
```
In the future, I will add a quick fix to convert these into the correct
types.
Fixes#16550
* Completion for default export should be '.default'
* Don't include empty string in name table
* getSymbolsInScope() should return local symbols, not exported symbols
* Fix bug: getSymbolAtLocation should work for local symbol too
