Consider switching to an alternate activation expression for the extension
Closed this issue · 4 comments
This issue is submitted in order to continue discussion alternate solutions to a problem expressed in #92.
The only suggestion so far assumes that there's a special setting added to the settings.json for the project, thus the extension could potentially rely on that to shortcut the full load based on the presence of the setting. However, this would replace the current detection functionality (which is based on the detection of the *.Tests.ps1 files) hence change the usual experience.
Is there any better way to handle it without breaking the standard behavior? Is it possible to have a system-wide setting that would dictate the extension which detection method to use (i.e. either file based or project setting based)?
Thanks!
The problem really comes down to that the activation options API in vscode are really limited, and since this extension is kind of heavyweight to load despite my best efforts to lazy-load everything, we would need some kind of custom bootstrap logic to only load based on that criteria (but the extension will still show as loaded in VSCode). That's a lot of work with minimal benefit compared to other targets so I personally am not going to work on this for a while so flagging as help wanted.
@JustinGrote, The workaround that I'm using right now is VSCode Profiles (thanks to your advice in https://www.youtube.com/watch?v=1Tk8n47xiIA session. Basically, I've just created a dedicated profile where I'm just keeping the extensions that I use for PowerShell development and the issue is gone.
@Glober777 glad to hear! Actually since I referenced this, VSCode added a lazy extension load API so that certain extensions load last, because of that I'm more able to possibly implement this because it also solves an issue where if you start a workspace and don't have any .tests.ps1 files and you create one, it doesn't activate the extension and you have to reload vscode.
I appreciate the follow-up!
This has been updated per #92 and I don't plan to support any way to initialize the Pester Test controllers at this time other than having a file that matches the filewatchers present (you can customize the search patterns as a setting), however now if you add a Pester file to a new workspace the controllers will activate properly due to the lazy load (they wouldn't before).
Ephemeral Pester Testing like live refreshing an untitled powershell file is a possible consideration but not a priority at the moment.