Change activation event to `workspaceContainers`

[SethFalco]

Describe the bug

Currently, the extension is set to activate on startup.

I'm looking through the activation events of all my extensions since lately, I've noticed some of them activate eagerly even when they don't apply to my workspace, which makes the startup slower and uses more resources on my system. This adds up when you have many extensions, i.e. I have 92.

VSC provides an activation event for when a certain file pattern is matched in the workspace:

https://code.visualstudio.com/api/references/activation-events#workspaceContains

Do you think it would be feasible to move the activation event for this extension from * to workspaceContains?

For example:

{
  "activationEvents": [
    "workspaceContains:**/*.xml",
    "workspaceContains:**/lcov.info"
  ]
}

Activate if the workspace contains an XML file, or lcov.info.

Desktop (please complete the following information):

• OS: linux
• Extension Version v2.10.2
• VSCode Version:

Version: 1.75.0-insider
Commit: f076d553210e9ea65e7bccbfa2f7a786c10fcab2
Date: 2022-12-09T09:09:03.185Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Linux x64 6.0.0-5-amd64 snap
Sandboxed: Yes

Additional context

• https://github.com/microsoft/vscode/issues/157499

Note, if workspaceContains might not be appropriate, we could still consider moving it from * to onStartupFinished.

This activation event is emitted and interested extensions will be activated some time after VS Code starts up. This is similar to the * activation event, but it will not slow down VS Code startup. Currently, this event is emitted after all the * activated extensions have finished activating.

— https://code.visualstudio.com/api/references/activation-events#onStartupFinished

For example:

{
  "activationEvents": [
    "onStartupFinished"
  ]
}

[ryanluker]

@SethFalco Thanks for the ticket!

Definitely would be better to turf the on startup instantiation of this extension (this was the only option when I initially developed it, I think...).

I like both ideas, but I think it is reasonable to only load the extension if an applicable file is found. I do wonder about how we might consider other file types not defined in the default list.

https://github.com/ryanluker/vscode-coverage-gutters/blob/master/package.json#L129-L135

[SethFalco]

I do wonder about how we might consider other file types

Unfortunately, I don't think VSC has a way to change activation based on settings, so if you're expecting users to specify additional files that are not info.lcov or **/*.xml, then the only option would be onStartupFinished I think. :thinking:

Some other extensions have a similar issue, for example SonarSource/sonarlint-vscode, prettier/prettier-vscode, and microsoft/vscode-eslint could just specify to only activate on the list of officially supported languages, but users can also have plugins/projects/settings that define or target other languages, so even if it's not too often, they need to use onStartupFinished instead.

Fine with using onStartupFinished at least, though?

[ryanluker]

@SethFalco Agreed that onStartupFinished sounds like a good first step! Thanks for the links to over extensions as well, it looks to be the norm to use this event instead which is nice to keep inline with the community 👍🏻.

[ryanluker]

@SethFalco Thanks again for the contribution and the PR, the change should go out in 2.11.0