Previously, the binder didn't check for a declared function named
'require' when binding require in JS. It unconditionally treated
'require' as the commonjs function, even when a local function named
'require' existed and even in ES modules. Now, the binder checks for a
local function named require and avoids binding in that case.
Both before and after, actually importing the module causes the checker
to issue an error saying that top-level functions named 'require' are
illegal. But this error doesn't show up until you've imported from the
module, so you won't notice it in the editor, where JS errors are most
useful.
Within-binder checks for declared functions are dependent on binding order, but
function binding simulates hoisting by binding all function declarations
first, so it should be pretty reliable.
* Add test where module resolution cache is not local and hence doesnt report errors in watch mode
* Ensure module resolution cache is passed through in watch mode
* Remove unnecessary setting of impliedFormat which should anyways be done as part of create source file
* Add test for packge.json changing and modifying implied format
* Distinguish between package.json watch and affecting file location watch
* Pass in failed lookup and affected file locations for source file's implied format
Also stop creating options if we already have them
* Add diagnostic for explaining file's implied format if based on package.json
* Watch implied format dependencies for modules and schedule update on change
* For program if implied node format doesnt match create new source file. Handle implied node format in document registry
Fixes#50086
* Modify tests to show package.json being watched irrespective of folder its in
* Check file path if it can be watched before watching package.json file
* Because we are watching package.json files and failed lookups its safe to invalidate package json entries instead of clearing them out everytime program is created
* Remove todos
* Fix the incorrect merge
* Pickup PackageJsonInfo renames from #50088
* Rename
* Improve import type support for commonjs exports
This PR makes getTypeFromImportTypeNode a little more like
getExternalModuleMember: for JS files, it now uses both
`getTypeOfSymbol` and `getExportsOfSymbol`, and uses whichever one
returns a symbol. This allows using arbitrary properties of a CJS export=
as types in JSDoc; previously a special case in the binder enabled only
CJS export= where all properties were shorthand assignments.
Fixes#49195
* Add js types/value test case
* Improve binding of CJS property assignments
1. Bind property assignments same as shorthand property assignments in
module.exports object literal assignments.
2. Bind all such assignments, even if the object literal contains
non-property assignments. This is different from before, and it requires
slightly smarter code to prefer aliases when checking CJS imports.
* Remove new binder code
Just include the original fix
* revert missed type in binder
* Add test where the errors are reported in different file
Test for #49739
* Report error only on local declaration with additional related information
Fixes#49739
* Handle existing tests
* Account for type parameters in missing function codefix
* Apply suggestions from code review
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* WIP
* Synthesize new type parameters instead of deep unions and intersections
* Pass along type parameter constraints
* E.T. phone home
* Clean up comments just a bit
* Only widen the instance type sometimes
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* fix(49719): omit TS2301 error with enabled usedefineforclassfields
* show error for target lower than esnext with useddefineforclassfields enabled
* change target from esnext to es2022
