* eng: onboard to the extension test runner
Adds a `.vscode-test.js` file that uses the new extension test CLI to
run tests. Also, onboards the markdown-language-features as the first
built-in extension to use it.
With the `ms-vscode.extension-test-runner` extension installed, the
markdown-language-features' tests can be run and debugged easily in
the UI :)
* fixup
Second attempt at this, which should work. Stop trying to use
exposeFunction, which seems to work poorly on macOS webkit in CI, and
just run a server with HTTP endpoints to do the "RPC."
Reuses Alex's "yaserver" module that we were already using for other
tests. Uses a secure random prefix for security in each run.
Should fix the issue that @roblourens and @Yoyokrazy were hitting with snapshot tests on macOS WebKit in CI. Not pretty, but I'd rather do this than spend a bunch of time chasing down something that certainly seems to be a browser issue.
* eng: add support for snapshot tests
This adds Jest-like support for snapshot testing.
Developers can do something like:
```js
await assertSnapshot(myComplexObject)
```
The first time this is run, the snapshot expectation file is written
to a `__snapshots__` directory beside the test file. Subsequent runs
will compare the object to the snapshot, and fail if it doesn't match.
You can see an example of this in the test for snapshots themselves!
After a successful run, any unused snapshots are cleaned up. On a failed
run, a gitignored `.actual` snapshot file is created beside the
snapshot for easy processing and inspection.
Shortly I will do some integration with the selfhost test extension to
allow developers to easily update snapshots from the vscode UI.
For #189680
cc @ulugbekna @hediet
* fix async stacktraces getting clobbered
* random fixes
* comment out leak detector, for now
* add option to snapshot file extension
* build: add watch/compile tasks for CLI
I spent time this morning working on the 'developer experience' of the
CLI in vscode, mainly getting the CLI to cross-compile chasing our
initial idea of having it auto-build in a devcontainer.
After some effort and disabling tunnels connections (to avoid having to
pull in OpenSSL which is a huge pain to cross compile), I was able to
get it to cross-compile from Linux to Windows, using the mingw linker.
I could probably figure out how to get macOS working as well with more
effort. However, I'm not a big fan of this, effectively it's one more
'platform' of build we need to support and test.
I think a better approach is downloading the latest compiled CLI from
the update server instead, as needed. That's what this PR does. It just
places the CLI where it _would_ normally get compiled to by cargo; so
far we don't need to do anything special outside of that.
A notice is shown to users if this fallback happens.
* update from review
