In the next commits we'll turn these rules on, one-by-one, and then
autofix the offenses.
At the end we'll be left with the rules that require manual attention.
This adds tests for the `loadResults` method of the variant analysis
results manager. It tests that SARIF results can be successfully
loaded and that the `onResultLoaded` event is fired.
The monitor return value was only used in tests, but we can also assert
the correct behavior using the calls it makes, rather than using the
result of the monitor.
The header color of a stat item was using the badge foreground color,
but badges can have a different background color than the editor. For
some themes, this would result in unreadable text. By using the editor
foreground color, the header should be readable in many more themes.
This adds four new VSCode themes to Storybook which will allow us to
more easily test these themes in Storybook. These themes were chosen
because they are either used for accessibility (the high contrast
themes) or are currently not compatible with the variant analysis UI
(there are items that are not visible).
When results were already cached in memory and the view requested the
result, it would not be loaded because the event would not be fired.
This fires the event when the result is loaded from cache as well, to
ensure that the view always receives the result.
This will stop the variant analysis monitor from monitoring when a
variant analysis is removed from the query history. Since the variant
analysis monitor cannot depend on the variant analysis manager (this
would create a circular dependency), a function is passed into the
variant analysis monitor for checking whether the variant analysis
should be cancelled.
This commit will also ensure that even if a variant analysis comes in
through the `onVariantAnalysisChange` callback, it won't be added to
the variant analysis map of the manager.
On Windows, we were showing the full path to the query, rather than just
the filename. This is because the `path` package being imported was
actually `path-browserify` which only claims support for POSIX. Since
Windows uses backslashes rather than forward slashes for paths, this
resulted in the full path being shown.
This creates a new `basename` function that works on both POSIX and
Windows by detecting whether a POSIX or Windows path is given. This
ensures that the correct path is shown on Windows, and will also ensure
that we show the correct path on Linux if the user has opened a variant
analysis that was originally created on Windows.
This will update the `jest-runner-vscode` patch to retry tests that fail
due to no test result being returned from the test runner.
This will also add some retries to the `minimal-workspace` and
`no-workspace` tests to help with flakiness.
Multiple VSCode instances were being launched when a second instance of
VSCode was being spawned with the same user data directory. This is
probably because VSCode restores the windows from the previous session,
even when `-n`/`--new-window` is passed.
This fixes it by patching `jest-runner-vscode` to always create a new
temporary user data directory, rather than re-using the same one for
all test suites.
This will patch `jest-runner-vscode` to retry tests. This is a temporary
test to see if this will help with the flakiness of the CLI integration
tests.
The biggest problem with this is that it will launch multiple VSCode
instances on every retry:
- First try (not a retry): 1 instance
- Second try: 2 instances
- Third try: 3 instances
- etc.
I'm not sure why this is happening and can't really narrow it down to a
specific cause. Even if I change the `runVSCode` call for the retry by
a simple `cp.spawn` call, it still launches multiple instances.
