* 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
* 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
Build, install and run:
gulp vscode-linux-packages
sudo dpkg -i out-linux/vscode-amd64.deb
code .
Installing the package does the following:
- Puts VSCode dir at /usr/share/code
- Puts code.sh launcher in /usr/bin
- Defines a .desktop file to properly integrate with the launcher
Fixes#2679
