The diagnostics reporting and expression resolution caching is quite intermingled at present.
Hence when we tried to get the declaration output without getting diagnostics, the resolution for functions return expression is cached but errors arent reported
Symbols arent marked as referenced. So at later time when trying to get the diagnostics since the expression resolution is cached, it doesnt even go through all checks
For now get diagnostics irrespective of declaration only output to avoid this issue.
Fixes#21518
* Integrate importStar and importDefault helpers
* Accept baselines
* Support dynamic imports, write helpers for umd module (and amd is possible) kinds
* Accept baselines
* Support AMD, use same helper initialization as is normal
* update typechecker to have errors on called imported namespaces and good error recovery with a quickfix
* Overhaul allowSyntheticDefaultExports to be safer
* Put the new behavior behind a flag
* Rename strictESM to ESMInterop
* ESMInterop -> ESModuleInterop, make default for tsc --init
* Rename ESMInterop -> ESModuleInterop in module.ts, add emit test (since fourslash doesnt do that)
* Remove erroneous semicolons from helper
* Reword diagnostic
* Change style
* Edit followup diagnostic
* Add secondary quickfix for call sites, tests forthcoming
* Add synth default to namespace import type, enhance quickfix
* Pair of spare tests for good measure
* Fix typos in diagnostic message
* Improve comment clarity
* Actually accept the updated changes to the esmodule interop description
* ESModule -> esModule
* Use find and not forEach
* Use guard
* Rely on implicit falsiness of Result.False
* These should have been emit flags
Timestamps look like Gulp's, with grey times inside white brackets.
Files have cyan filenames, yellow line and column numbers, and grey TS{####} errors. I wonder if those are actually useful for folks using the --pretty CLI: are they used for anything outside Visual Studio... Can we just get rid of them?
Re-uses compiler/program's color logic in compiler/watch. The relevant variables are now exported and marked `@internal`. Is there a preferred way of re-using this code in both those files?
This allows reporting of semantic errors as well. Semantic errors are
likely to outnumber syntactic errors, so it's valuable not to block
semantic errors on a few syntactic errors.
* Add utility function to check for strict option flags
- Correctelly check for noImplicitAny in checker
- Correctelly check for noImplicitAny in installTypesForPackage refactor
* Respond to code review comments
* Accept baselines
* Revert "Accept baselines"
This reverts commit cf4ef62830b4ee5555125ce214d824e16c244488.
* Move type alias to core
This marks files reused correctly as from external library resulting in not using them for files to be emitted and computed for output structure
Fixes#19327
