* Prototype TS plugins on web
This prototype allows service plugins to be loaded on web TSServer
Main changes:
- Adds a new host entryPoint called `importServicePlugin` for overriding how plugins can be loaded. This may be async
- Implement `importServicePlugin` for webServer
- The web server plugin implementation looks for a `browser` field in the plugin's `package.json`
- It then uses `import(...)` to load the plugin (the plugin source must be compiled to support being loaded as a module)
* use default export from plugins
This more or less matches how node plugins expect the plugin module to be an init function
* Allow configure plugin requests against any web servers in partial semantic mode
* Addressing some comments
- Use result value instead of try/catch (`ImportPluginResult`)
- Add awaits
- Add logging
* add tsserverWeb to patch in dynamic import
* Remove eval
We should throw instead when dynamic import is not implemented
* Ensure dynamically imported plugins are loaded in the correct order
* Add tests for async service plugin timing
* Update src/server/editorServices.ts
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Partial PR feedback
* Rename tsserverWeb to dynamicImportCompat
* Additional PR feedback
Co-authored-by: Ron Buckton <ron.buckton@microsoft.com>
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Use node ipc for TS Server
For #46417
This lets us use Node's built-in ipc for passing messages to/from the typescript server instead of using stdio
* Remove extra parse
* Add extra logging when using node IPC
* Split out to subclass
* Extract common writeMessage method
* Baseline accept
* Add a basic dev container
Adds a basic dev container. This basic development environment has tools like gulp installed
* Update CONTRIBUTING.md
* Move development container seciton to be first tip
* Spaces to tabs and remove comments
Co-authored-by: Daniel Rosenwasser <DanielRosenwasser@users.noreply.github.com>
* 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>
* Check to make sure default npm exists at path before trying to use it
**Bug**
If the typings installer is run under a copy of node that does not include npm—but on a machine that does have npm installed—it will incorrectly try to use the npm that does not exist next to its running version of node
**Fix**
Make sure that we check that npm we select exists before trying to use it as the default. Otherwise, fall back to using plain old `npm`
* Add command line flag to gate new behavior
* Fix missing semicolon
* Add kindModifier to mark if a completion item is for an optional field
For #12458
Adds a new KindModifier for completion items to mark when a property is optional. This can be used by editors to either change the item icon or add a `?` to the item text
* Add method test
* Baseline-accept
* Print TS Server version and args in logs
Fixes#18867
Adds basic logging of the version of tsserver being run and the full command line arguments used to run it
* Don't check log level for logging versions/args
Fixes#18322
Ensure that we also try to load global plugins for inferred projects. Moves global plugin loading logic to base `Project` class from `ConfigureProject` .
**Bug**
While investigating #15301, I was confused by the typing installer's log `Updating types-registry npm package...`. This was often the last line of the log file, leading me to believe that the types-registry update was still ongoing
**Fix**
Add an extra log for when the type-registry update completes successfully
While working on https://github.com/Microsoft/vscode/pull/22437, I believe there is a bug in the per request cancellation in the `setRequest` function on the line `currentRequestId = currentRequestId ;` This causes `currentRequestId` to always be undefined
Fix is to assign the `currentRequestId` to `requestId`
