Do you need onStartupFinished?

[TylerLeonhardt]

👋 onStartupFinished means that your extension will always activate even when the user has no intension of using CodeSwing.

https://github.com/lostintangent/codeswing/blob/3117534267e74aafffcb80a8adb1fae6e1e05ab9/package.json#L29

Is there a reason you have onStartupFinished? I'm wondering if there's a gap in VS Code's API.

[jasonwilliams]

@TylerLeonhardt you may want to see the conversation here https://github.com/lostintangent/codeswing/issues/22

[TylerLeonhardt]

Is such extensibility needed with the trade off of an extension that will always be activated even when it's not used?

[lostintangent]

Your original question seemed to indicate that you were curious about extensibility gaps, that would prevent the need for the use of onStartupFinished? In the case of CodeSwing, we'd need the ability to have dynamic "workspace contains" activation events (which I could imagine other extensions benefiting from?)

I'd prefer not to remove the logic that depends on this behavior, since I'm working on some extensions to CodeSwing for supporting other languages.

[TylerLeonhardt]

@lostintangent maybe I'm missing something in this scenario but this should work:

myExtension has the following in the package.json:

"activationEvents": [
        "onCommand:activation-test.helloWorld"
],
"extensionDependencies": [
		"tyler.myOtherExtension"
],

myOtherExtension has the following in the package.json:

"activationEvents": [
        "onCommand:some-other.randomCommand"
],

From my testing, if I activate myExtension by triggering its activation event "onCommand:activation-test.helloWorld" then myOtherExtension will get activated because it is marked as an Extension Depedency.

So I would think that to do what you wanna do:

• remove onStartupFinished from CodeSwing
• Have the extension responsible for the extensibility:
  • provide the activation event that you want (so "workspace contains myspecialfoo.file")
  • have codeswing as an extension dependency

That way CodeSwing will be activated when needed by the extension, and it's not activated all the time when it's not needed.

[lostintangent]

The CodeSwing extension defines a set of "base" files names that it looks for ("index", "App", "main", "script", "style"), and then extensions can provide language support based on specific file extensions (".pug", ".go", etc.). And so in order to determine whether a workspace represents a swing, that should be automatically opened, CodeSwing needs to "merge" the set of base names + known file extensions on activation, and inspect the workspace for them. As a result, neither CodeSwing, nor the extending extensions would be able to statically know which files they were looking for in the workspace, and use that to drive activation.

Theoretically, an extending extension could hardcode a series of "workspace contains" file paths, using their known file extensions + some static set of CodeSwing "base" file names (e.g. "index.foo", "App.foo", etc.), but then if CodeSwing introduced a new base file name, the companion extension wouldn't properly activate for it. At the moment, this decoupling makes it really simply for an extension to simply add support for a new language for CodeSwing, without needing to deal with any of the details at all.

[TylerLeonhardt]

but then if CodeSwing introduced a new base file name, the companion extension wouldn't properly activate for it

Why would this companion extension want to activate for some new base file name that it itself doesn't support? Can you give an example of when this has happened/would happen?

---

Activation Events are totally static as you know so let's think about some other options that are static besides "dynamic 'workspace contains' activation events".

Can we turn it around and say "this extension needs to activate when that extension activates"? And so the companion activates when CodeSwing activates? I wonder if this can somewhat be achieved today using: onWebviewPanel:<id of the CodeSwing WebView>

[jasonwilliams]

Why would this companion extension want to activate for some new base file name that it itself doesn't support?

I agree, it doesn’t make sense to go down that path.

It sounds like CodeSwing should have it’s own static base paths it checks for and extensions have their own static paths they check for. If an extension finds what they’re looking for they can trigger codeswing like @TylerLeonhardt showed.