refactor: Activate on onStartupFinished

[adalinesimonian]

Closes #214

Stops this extension from slowing VS Code during startup.

[adalinesimonian]

Supercedes #215. @robole created the issue and the initial PR and will be given credit for this fix.

Disregard the v1- prefix in the branch name; this PR is meant to target main.

[adalinesimonian]

This change seems to result in inconsistent document formatting test results. In three attempted test runs, all 3 failed on Ubuntu and 1 failed on macOS. Will need further investigation.

[ota-meshi]

We'll probably have to wait for this extension's formatter to become available for formatter tests to stabilize.

For example, it test is waiting for the command to be available.
https://github.com/stylelint/vscode-stylelint/blob/main/test/workspace/validate/index.js#L12

[robole]

@ota-meshi If you want to speed up the tests, you could open one of the test files in a before() and wait for the extension to be active, and then all subsequent tests will reliably be able to run commands without waiting for that particular file to activate the extension. The extension takes approx 200ms to become active, so if you load a new file in each test case to activate the extension like some of the test files do, it will add that time to each test case. Its just a question of whether you prefer to verify when the extension is active each time or not.

The alternative is to reorganise some of your tests to focus on a particular language, bundle CSS tests together, bundle SCSS tests together..etc.

[adalinesimonian]

We'll probably have to wait for this extension's formatter to become available for formatter tests to stabilize.

@ota-meshi I was trying to find some way in the API to get a list of registered document formatters, but I couldn't find what I was looking for. I searched in the vscode repository and was able to find code which retrieves a list of formatters, but it seems to be part of a private API that isn't exposed publicly. Is there another way you know of?

If you want to speed up the tests, you could open one of the test files in a before() and wait for the extension to be active, and then all subsequent tests will reliably be able to run commands without waiting for that particular file to activate the extension. The extension takes approx 200ms to become active, so if you load a new file in each test case to activate the extension like some of the test files do, it will add that time to each test case. Its just a question of whether you prefer to verify when the extension is active each time or not.

I'm not sure I understand — with onStartupFinished, doesn't the extension activate some time around VS Code's startup? We have a global beforeAll that waits for the extension to be active. Each group of test suites in test/workspace that runs in VS Code needs to run in a different workspace to run with workspace-specific context and configuration, so they're all being run in their own VS Code process as it is. There's no way to get VS Code to open multiple workspaces from one test because the extension host, which is where the tests run, restarts whenever you change workspaces. So either way, we'd be waiting each time for the extension to activate, as we do now, unless I'm missing something?

[ota-meshi]

Is there another way you know of?

I don't know the another way 😓

[adalinesimonian]

I've brought this use case up over at microsoft/vscode#135674

[Lemmingh]

We have a global beforeAll that waits for the extension to be active.

The code you quoted does "wait for at most 2000 ms and report whether it's activated".

What about explicit activation:

const vscodeStylelint = extensions.getExtension('stylelint.vscode-stylelint');
await vscodeStylelint.activate();

[adalinesimonian]

The code you quoted does "wait for at most 2000 ms and report whether it's activated".

What about explicit activation:

pWaitFor rejects if the condition isn't true by the time the timeout lapses, so if the extension wasn't being activated in time we would see an error in tests/CI when that happens. However, beforeAll isn't throwing any errors, which means that the extension is activated by the time the formatting test runs. The failure is happening due to the formatter not being available at the time that the format command is executed, you can see this happening in CI logs.

[ota-meshi]

LGTM!