* Watch extended configs if present
* Address code review comments
Added new `WatchType` for extended config files. Refactored watch map
update to separate function, relocated call sites. Removed unnecessary
test cases and relocated with new tests in programUpdates.
* Unify extended config file watching between tsc/tsserver
Update `updateExtendedConfigFilesWatch` to read from a
`TsConfigSourceFile` to get `extendedSourceFiles`. Add watcher map to
`ConfiguredProject` in the server. New test cases to verify correct
events triggered and extended files are being watched properly.
* Simplify watcher callback, fix tests
Removes unnecessary actions in extended config watcher callback
function. Updates tests to match.
* Share extended config watchers across projects in server
New shared watcher map in ProjectService that stores callbacks per
project to be invoked when the file watcher is triggered. The
FileWatcher is created with the watch options of the first Project to
watch the extended config.
* Refactor shared extended config map and watchers
Remove all server-related utility functions/types from
watchUtilities. Store config-project mapping and config file watchers
inside ProjectService with new private methods to add or remove
projects.
* Store projects in extended config file watcher
Creates SharedExtendedConfigFileWatcher in both editorServices
(tsserver) and tsbuildPublic. The file watcher is responsible for
triggering a full project reload for the contained projects. Upon
reload, any configs that are no longer related to a project have their
watchers updated to match. New test cases to confirm that the file
watchers for extended configs are closed when the project is closed.
* Apply suggestions from code review
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Map extended config files by path
* Move shared watcher into utilities and add more tests
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Detect comparisons between large unions or intersections
If their multiplied size is greater than 1E6 (chosen based on the repro
in #41517), then we'll expend a large amount of time and memory
comparing them, so record a trace event.
Related to #41517
* Make an exception for primitive union comparisons
* Address PR feedback
* Pick up baseline change from master
* Eliminate diagnostic and only trace
* Don't check reportErrors
* --explainFiles currently hardcoded
* Move configFileSpecs to configFile so it can be used in program later
* Explain root file inclusion reason and explain include files in the log
* Baseline explainFiles
* Fix incorrectly reporting of file list two times in --b mode
* Fix unnecessary new lines in output represented incorretly in the baseline
* More tests
* More cleaning up
* Keep listing files in same order as list files, just add explaination
* Fix double listing of file names when the program has errors
* Make diagnostic chains for file include reason
* Add explaination for the file include to diagnostics for program
* Harness ls incorrectly adding tsconfig as the root file
* Fix incorrect use of path for calculating absolute path
* Fix the root file in fourslash
* Test project service options merge
* Add config file name to matched by include explaination
* Add test for when the file changes and program is reused completely but related file information is reattached to correct location
* Handle file preprocessing diagnostics updates when program is reused and related information location changes
* Moved types to types.ts
* Refactoring and cleanup
* More cleanup
* More refatoring
* Handle synthetic imports
* Baselines after merge
* Adds experimental support for running TS Server in a web worker
This change makes it possible to run a syntax old TS server in a webworker. This is will let serverless versions of VS Code web run the TypeScript extension with minimal changes.
As the diff on `server.ts` is difficult to parse, here's an overview of the changes:
- Introduce the concept of a `Runtime`. Valid values are `Node` and `Web`.
- Move calls to `require` into the functions that use these modules
- Wrap existing server logic into `startNodeServer`
- Introduce web server with `startWebServer`. This uses a `WorkerSession`
- Add a custom version of `ts.sys` for web
- Have the worker server start when it is passed an array of arguments in a message
In order to make the server logic more clear, this change also tries to reduce the reliance on closures and better group function declarations vs the server spawning logic.
**Next Steps**
I'd like someone from the TS team to help get these changes into a shippable state. This will involve:
- Adddress todo comments
- Code cleanup
- Make sure these changes do not regress node servers
- Determine if we should add a new `tsserver.web.js` file instead of having the web worker logic all live in `tsserver.js`
* Shim out directoryExists
* Add some regions
* Remove some inlined note types
Use import types instead
* Use switch case for runtime
* Review and updates
* Enable loading std library d.ts files
This implements enough of `ServerHost` that we can load the standard d.ts files using synchronous XMLHttpRequests.
I also had to patch some code in `editorServices`. I don't know if these changes are correct and need someone on the TS team to review
* Update src/tsserver/webServer.ts
* Update src/tsserver/webServer.ts
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Addressing feedback
* Allow passing in explicit executingFilePath
This is required for cases where `self.location` does not point to the directory where all the typings are stored
* Adding logging support
* Do not create auto import provider in partial semantic mode
* Handle lib files by doing path mapping instead
* TODO
* Add log message
This replaces the console based logger with a logger that post log messages back to the host. VS Code will write these messages to its output window
* Move code around so that exported functions are set on namespace
* Log response
* Map the paths back to https:
// TODO: is this really needed or can vscode take care of this
How do we handle when opening lib.d.ts as response to goto def in open files
* If files are not open dont schedule open file project ensure
* Should also check if there are no external projects before skipping scheduling
Fixes failing tests
* Revert "Map the paths back to https:"
This reverts commit 0edf650622.
* Revert "TODO"
This reverts commit 04a4fe7556.
* Revert "Should also check if there are no external projects before skipping scheduling"
This reverts commit 7e4939014a.
* Refactoring so we can test the changes out
* Feedback
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Loosen author tag parsing
Also make the code more efficient and easier to read.
1. Arbitrary text, except for newline and @, is allowed for the author name.
2. Arbirtrary text, except for newline, is allowed for the email
address.
3. Newline is treated as a match for an open <
I tried to allow newlines in the author and email, but it was ambiguous
with the end of the tag.
I also got rid of the two lookaheads and unified the trailing comment
handling.
Fixes#41804
* remove hardmode test since it did not reveal anything new
* Baseline showing #41801 and other issues with output path calculation
* Add a way to note descripencies between clean and incremental build
* Add descripency when no rootDir is specified but project is composite
* if rootDir is specified, irrespective of whether all files belong to rootDir, the paths should be calculated from rootDir
* Fix the output file names api to use the correct common source directory
* Tests for #41780
* Spelling
* Less aggressive wildcard check, 'keyof any' constraint for 'infer T' in mapped type constraint position
* Accept new baselines
* Add regression tests
* Allow type-only ImportEqualsDeclarations
* Suppress CJS-in-ESM error when type-only
* Add grammar error on import type in import alias
* Update API baselines
* Fix importsNotUsedAsValues with ImportEqualsDeclarations
* Make bad error talk words more good for Daniel. Fixes#41603
* One more error message baseline update
* Update transformer and emitter
Fixes#41586Fixes#41588
1. For binary expressions, if the immediate parent is an IfStatement,
then check the body of the if statement. I didn't walk upward to find an
IfStatement because in my experimentation I found that binary expression
uncalled-function errors are only issued when the expression is on the left of the
top-most binary expression.
2. For property accesses with interspersed calls, I added a
CallExpression case. In fact, any expression could appear here, but I
only want to fix calls for now since that's all we've observed in
Definitely Typed, and we didn't see anything else in the user tests or RWC
tests. I also didn't examine parameters of the intermediate call
expressions, but I don't think it's needed since the intent is to avoid
false positives.
