Provide extensions with additional context in activation method

[eamodio]

It could be very helpful to provide some additional context into how/why an extension is being activated.

The main motivation for this to allow extensions to more easily/accurately decide on when to have certain "welcome" like experiences or avoid them in the many cases where they are not desired.

For example, if an extension was told in its activate method that it was just installed by the user directly (or through an extension pack), the extension might assume that a "welcome" experience might be desirable. But if the extension was installed because of settings sync, then a "welcome" experience is almost certainly NOT desirable.

Also by "welcome" experience, it could be anything from showing a webivew, notification, or merely switching to a view, etc.

Technically this can be achieved today, with sync'd keys, but it isn't simple to adopt and requires many extensions to do the same work.

Alternatively, instead of a "install" reason, maybe VS Code just does the "sync" work to provide a firstRun flag, so that an extension could just simply use that for its determination.

Additionally, it would be very nice (but largely out of scope for my specific ask here), would be provide the activation event (e.g. the reason) the activate method is getting called. For example, if you are getting activated because of a command, you might change your startup behavior.

If we decide to not do anything here, I would suggest that we add a sample/documentation on how an extension can implement this beahvior.

[tamuratak]

Related to #44711.

[alexdima]

@sandy081 IMHO, I think extensions have been using a pattern where they show a welcome screen on activate by checking for a memento and then saving the memento once the Welcome screen is shown. This worked well, but worked well only on a single machine.

I like the idea to introduce explicit API like e.g. ctx.canShowWelcome. Given the deep connection with settings sync and command line installation (e.g. extension installed due to devcontainer.json), I think you would be a natural fit to own this API. You would know better than me, perhaps this could be implemented straight-forward with global state syncing.

A special API that is provided by vscode has the benefit that we could explicitly set ctx.canShowWelcome to false when we really don't want to show welcome screens, like e.g. when using vscode as a git commit message editor, or reviewing a PR in codespaces, etc.

---

Additionally, it would be very nice (but largely out of scope for my specific ask here), would be provide the activation event (e.g. the reason) the activate method is getting called. For example, if you are getting activated because of a command, you might change your startup behavior.

This has been requested before in #44711 . See #44711 (comment) for more background on why it might not be desireable to define a closed set of activation reasons, since those reasons might grow over time. (2a, 2b were added later)

[sandy081]

/duplicate

#83451

[eamodio]

@sandy081 I don't really think this is a duplicate -- this is just about extra activation "context" where some of that could be used for a welcome experience. It could also be used for startup optimization, etc. Additional context, could be how the extension was installed -- manually, manually via pack, sync, recommendation, etc, etc.

[sandy081]

@eamodio Opening this to understand more about your request - Can you please explain more about the use cases other than welcome experience?