If these are regular comments, then they won't appear in our d.ts files.
But, now we are relying on an external d.ts bundler to produce our final
merged, so they need to be present in the "input" d.ts files, meaning
they have to be JSDoc comments.
These comments only work today because all of our builds load their TS
files from scratch, so they see the actual source files and their
non-JSDoc comments.
The comments also need to be attached to a declaration, not floating,
otherwise they won't be used by api-extractor, so move them if needed.
This step converts as many explicit accesses as possible in favor of direct imports from the modules in which things were declared. This restores the code (as much as possible) back to how it looked originally before the explicitify step, e.g. instead of "ts.Node" and "ts.Symbol", we have just "Node" and "Symbol".
This step converts each file into an exported module by hoisting the namespace bodies into the global scope and transferring internal markers down onto declarations as needed.
The namespaces are reconstructed as "barrel"-style modules, which are identical to the old namespace objects in structure. These reconstructed namespaces are then imported in the newly module-ified files, making existing expressions like "ts." valid.
* 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>
* Create different watch options in compiler options
* Thread through the new watch options
* Actually use the options passed through for watch strategy
* Support delay on updating child directory watches
* Make watchOptions separate from compilerOptions
* Support passing watch options from command line
* Handle displaying of watchOptions
* Move most harness globals into namespaces
* Remove forward declaration from `createMapShim` and move all `Map` declarations into one file
* A small pile of more changes to get the harness transforming
* Move insertSorted from server to core, use for diagnostic collections
* All keep the overall list sorted, too
* Increase timeout for js verification
* Use knowledge of how diagnostics are sorted to make all diagnostic list creation lazy and more efficient
* Staunchly avoid array allocation in favor of resizing an existing array
As with `SetTypings`, new typings have been installed so the project
should be updated and the client should be notified (via event).
Changed PackageInstalledResponse from "event" to "action" for the sake
of explicitness.
Fixes#20084.
Whitespace cleanup.
Switching back to protocol.ts and reenabling stripInternal.
Marking internal symbols indirectly exported by dependencies of protocol.ts as internal.
