* Make GetEditsForFileRenameRequestArgs not extend FileRequestArgs
* Code review: check new location first, and use scriptInfo.getDefaultProject()
* Remove changes to e getDefaultProjectForFile (now #25060)
* Undo API changes (#24966)
* Combine edits from all projects (fixes#25052)
* Update API (#24966)
* Ignore orphan projects or projects with language service disabled
* Add refactor to convert named to default export and back
* Support ambient module
* Handle declaration kinds that can't be default-exported
* Update API (#24966)
Previously, TypeScript would resolve the reified types for the
`design:types` decorator emit in the regular `currentScope`. That scope
does not include class declaration bodies.
However when reifying types, class declarations do introduce a new scope
for any `TypeVariable`s declared on them. Because TS resolved the
EntityName for such types against the parent scope (e.g. the source
file), not the class scope, TypeScript would either fail to resolve the type (giving `TypeReferenceSerializationKind.Unknown`), or
incorrectly resolve to a different, accidentally matching symbol in the outer scope (giving `TypeWithConstructSignatureAndValue`).
This would result in an emit referencing an undeclared symbol, or
mis-referencing the wrong symbol.
__metadata("design:type", typeof (_a = typeof TypeVariable !== "undefined" && TypeVariable) === "function" && _a || Object)
__metadata("design:type", TypeVariable)
This change special cases `currentScope` for
`serializeTypeReferenceNode` to use a class scope, if present. This
changes the emit for a `TypeVariable` back to `Object`:
__metadata("design:type", Object)
* Multifaceted approach to performantly enabling fileExists outside of the synchronize step in the emit host
* make cache undefinable and handle correctly
* Remove unneeded cast
* Readd assert
* More useful failure messager
That is, only nest them if their name matches the provided parent name.
Otherwise do not nest them.
Note that this commit changes the behaviour of an incorrect typedef that
contains both an `@type` child tag and `@property` child tags.
Previously, the `@type` would be incorrectly nested under a `@property`
tag with type `object`, just like `@property` tags would be. Now, the
`@type` tag causes the entire typedef to ignore the `@property` tags and
treat the typedef as if it were an instance of the
typedef-and-nested-type pattern:
```js
/**
* @typedef {Object} name
* @type {{ the, actual, type }}
*/
```
* Don't recommend to install '@types/foo' if that already exists
* Add different extra diagnostic text if the @types package exists
* Update API (#24966)
