* Static assignments to class expressions work
* Bind static properties of functions too
Also update SymbolLinks in getTypeOfFuncClassEnumModule so that the
type gets cached correctly.
* Remove initializer handling:obj literals+type lookup
Also include a couple of improved baselines
* Fix 1-nested js containers:binding+cross-file merge
* Consolidate check into one utility
The utility is horrible and needs to change, but at least it's in one
place.
Next step is to make the utility like getDeclarationOfAlias, except
getDeclarationOfJSAlias.
* Defaulted assignments now (mostly) work
* Default assignment definitely work, and IIFEs kind of do
* n-nested undeclared containers now seem to work
Merging even seems to work ok.
* Handle prototype+prototype property assignments
Perhaps in the wrong way. I have an idea how to simplify them.
* Remove prototype special-case
1. It's not completely removed; the checker code in
getJavascriptClassType needs to be fixed, among other places.
2. I didn't actually remove the code so that it will be easier to see
what used to be there on Monday.
Regardless, the code will be much simpler and seems to be mostly
improved with very little work so far.
* Allow more merges+accept baselines
* Update more baselines
* Fix js initializer check in bindPropertyAssignment
* Fix codefixes
* Rest of strictNullChecks cleanup + other cleanup
1. Remove a few TODOs
2. Remove extraneous SymbolFlag
3. Simplify isSameDefaultedName
* Binder cleanup
* Checker cleanup
* Almost done with utilities cleanup
* Utilities cleanup
* Require js initializer to be (1) JS (2) initializer
Change getDeclarationOfJSInitializer to require that the provided js
initializer be in a javascript file, and that it is the initializer of
the retrieved declaration.
* Use getSymbolOfNode instead of accessing symbol directly
* Ugh. Start over with just test cases
* Handle additional cases in getTypeOfVariableOrParameterOrProperty
These are cases in a really embarrassing check, in which we admit that
the symbol flags steered us wrong and switch to
getTypeOfFuncClassEnumModule instead (which never asserts).
* Add test case for #24111
* Address PR comments
* Fix resolution of exported types in commonjs
It is fine to resolve the types of exported classes in ES6:
```js
export class C {
}
var c = new C()
```
But not for commonjs exported classes:
```js
module.exports.C = class {
}
var c = new C() // should error
```
Fixes#24492
* All jsdoc type aliases are available locally in commonjs modules
* Check that location isSourceFile before commonJsModuleIndicator
* Add refactor to convert namespace to named imports and back
* Add tests and comments
* Code review
* Handle shorthand property assignment and re-export
* Don't use forEachFreeIdentifier
* Fix rename after "."
Before this change, when failed lookup location didnt fall in root directory,
we tried to find the ancestor directory of the rootDirectory to watch.
We also created subDirectory map for the directories that are being watched so we dont go through invalidation if path is unwanted directory
With this change, we will watch those subdirectories instead of root. On windows node supports file system level recursive watching so the earlier approach was better because we reduced number of watches created
But on other os, since node doesnt support it, we create the watches for existing folders outselves, so earlier approach becomes expensive.
This should be better compromize to satisfy both types of OS.
Fixes#24434
A bug in checkSpecialAssignment added bogus duplicate identifier errors
when using module.exports assignment to export a class. This commit
fixes that.
* Skip IntrinsicAttributes elaboration in JSX errors
Do not issue an error message for a source type that comes from JSX
attributes and a target type that is an intersection containing
IntrinsicAttributes or IntrinsicClassAttributes. This will make error
messages simpler and less confusing.
Note:
1. There will always be elaboration under the skipped message, so this
won't elide errors completely.
2. Rarely (once in the tests) the intersection type will have more that
one non-Intrinsic* member. However, these additional members don't
provide useful information either, so it's fine to skip them.
* Add test of IntrinsicAttributes error
* Fix indentation in test