It turns out that the import expression won't actally be rewritten by
esbuild, so we can just write it directly.
While this won't help CJS emit, that already didn't work anyway, and
it's likely that this code is going to be moved outside of the codebase
into VS Code or a shared package elsewhere anyway.
This eliminates a significant number of dependencies, eliminating all
npm audit issues, speeding up `npm ci` by 20%, and overall making the
build faster (faster startup, direct code is faster than streams, etc)
and clearer to understand.
I'm finding it much easier to make build changes for the module
transform with this; I can more clearly indicate task dependencies and
prevent running tasks that don't need to be run.
Given we're changing our build process entirely (new deps, new steps),
it seems like this is a good time to change things up.
This configures the existing build tasks to use esbuild by default. If
using the plain files is desired, passing `--bundle=false` will build
using plain files and still produce a runnable system.
This is only a basic build; a more efficient build is provided later
when gulp is replaced by hereby.
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>
* 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 0edf650622da11e89e42238523d57f3ea780cdcf.
* Revert "TODO"
This reverts commit 04a4fe75563ea9fe4747d42a4448d5dd421fbba5.
* Revert "Should also check if there are no external projects before skipping scheduling"
This reverts commit 7e4939014a414c7651f1fa01516c81a37a10e9be.
* Refactoring so we can test the changes out
* Feedback
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
