* 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
* Revert "Have English language return default result (#175157)"
This reverts commit 3c9f409888.
* Revert "Fix locale and language handling (#174779)"
This reverts commit 4e32196835.
* Revert "Add en as fallback osLocale (#175039)"
This reverts commit 7b6b6869e8.
* Revert "Ensuring locale is set to the OS locale and language is set to the Application Language (#174733)"
This reverts commit ecf479e662.
* Implement titlebar correctly using platformLocale
* Add more logging and perf markers around resolving the connection token and the socket factory
* set `exposeFunction` earlier
* bla windows
* also expose function for unit tests beofre opening
Co-authored-by: Benjamin Pasero <benjamin.pasero@microsoft.com>
* ipc: use vql for uint types
On the plane I was reverse-engineering ipc.ts to implement it in Rust
and see if we could have a "service mode" for the CLI that we could
interact with like any other vscode process.
In doing so, I noticed that numbers in the protocol--which are used at
least twice in the message header and ID--were encoded as JSON. I was
curious what benefits we'd get from encoding them as variable-length
integers instead.
It makes the message shorter, as expected. Encode/decode time are very,
very slightly lower. I'm not sure it's worth the extra complexity, but
I have included it here for your consideration.
* fixup tests
