* 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
* 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
* Highlight label should not create extra empty dom nodes
I noticed that the `HighlightedLabel` class creates extra `span` elements for text ranges. These should not be needed. Using text children directly should be faster for creation and also reduce the number of nodes in the document
I also related the conditional spread with a longer version that uses a simple call to push. This is worth doing since `HighlightedLabel` is so widely used in the editor
* Update tests
* Update smoke test selector
* Update css
* Remove vscode-notebook-tests in favor of an .ipynb in vscode-smoketest-express
* Update build folder
* Add build task to correct platform
* Build for smoke tests on other platforms
* Fix repo url and remove comment
* Just -media?
* Update darwin/win32 as well
Resubmission of #157532 with the following changes:
- Use `eslint-plugin-local` instead of `yarn` link to run our plugins
- Move our plugins to a top level `.eslintplugin` dir (as required by `eslint-plugin-local`)
- Update all names to `local/`
* Run our custom eslint rules using ts-node
Use `ts-node` to run our custom eslint rules. This lets us delete the pre-compiled js. It also means you can don't have to compile the rules while editing them
As part of this change, I've also switched us to using an eslint plugin instead of a rulesDir. This is now the preferred way to ship custom rules
* Fix two more disables
* Move ts-node to project root
* Enable transpileOnly
