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.
Now that we are modules, there's no reason to ban multiple namespaces
per file; each file is its own scope and declaring a namespace won't
merge it into any other files.
* 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>
Instead, search for stuff up the directory tree, with the main
functionality being to look for `Gulpfile.js` and assume the resulting
directory is the root.
(Unfortunatley, this is implemented twice, one in `scripts` and another
in `src`. It's not possible to use a single implementation for both
since that would require assuming a directory structure which this is
intended to avoid.)
Also, in `scripts/build/projects.js`, abstracdt common exec
functionality into a local helper, and use full paths based on the above
search instead of assuming relative paths assuming CWD being in the
project root.
Using shell-based execution is always a bad idea; this thing didn't do
that via an option, but instead did it manually by constructing a shell
command so it suffers from the same diseases.
Perhaps there was need for this at some point in the past, but things
are pretty robust now, so there's no need to avoid running the command
normally. The only thing that is needed is to add `which` which also
handles windows executable suffixes.
I tried this with a fresh clone on windows, where the tree and TS are
installed in paths that have spaces, and everything works as it should.
* Refactor emit substitution into transform
* Add reusable state machine for binary expressions
* Allow emitBinary to use state machine for comments/sourcemaps
* Switch core trampoline state back to arrays
* Switch binder to parallel stacks, temporarily partially revert emitBinary
* Add link to benchmark when posting perf results
* Ensure work stacks are per-execution
* Reenable comments and sourcemaps
* Remove playwright from package.json
* Install playwright on demand
* Adds debugging info to the playwright script
* Move installation first
* Get it working on node 10 again
* Update browserIntegrationTest.js
* Update browserIntegrationTest.js
Co-authored-by: Orta <git@orta.io>
