💡 [Feature]: Support debug option

[Adam-it]

🎯 Aim of the feature

Based on the problem we had in issue #278 it is not the first time that running local instance of CLI for M365, and related commands in debug, gave some answers on what could be the problem. This is some problem as the user needs to install CLI for M365 locally to make the double check which in general is not needed for this Toolkit to work.

The idea is to:

1. Add a VS Code setting to the extension, maybe a checkbox like 'run CLI commands in debug'
   

2. Setting this would add the --debug option to each CLI for M365 command and will show their output in the VS Code extension output logs. We should add the debug option when any CLI command is executed in this methods

   vscode-viva/src/services/CliCommandExecuter.ts

   Line 25 in b66d97f

   private static async tryExecuteCommand(command: string, output: string | undefined = 'text', args?: any): Promise<CommandOutput> {

[DevPio]

I would like to work on this problem

[Adam-it]

I would like to work on this problem

All yours.
Please keep in mind this issue participates in Hacktoberfest event so if you want this PR to count towards this event please be sure to open the PR during October (not sooner and not later 👍)

[DevPio]

I noticed that when I set the debug flag to true and then switch it back to false, the command responses still behave as if they are in debug mode. Do you know of any way to reset or clear the command responses when switching the flag back to false? From what I’ve researched so far, it seems like there isn’t anything that directly addresses this. Could you help me with this?

Another thing I noticed is that when entering debug mode, many outputs are directed to stderr. Most of these outputs are not actual errors, but since they fill stderr, there are validations in the code that treat any output in stderr as an error, preventing the flow from continuing. This happens, for example, during the deploy stage.

Could you guide me on how to proceed? I would like to help with this task.

[Adam-it]

I noticed that when I set the debug flag to true and then switch it back to false, the command responses still behave as if they are in debug mode. Do you know of any way to reset or clear the command responses when switching the flag back to false? From what I’ve researched so far, it seems like there isn’t anything that directly addresses this. Could you help me with this?

The way it works is that the debug is a flag. So it does not matter if we pass true or false as long as we add --debug then CLI will use this option to present debug info.
Just check it out when I run come CLI for M365 command in terminal passing --debug false. As you see I still get the debug info.

So in order not to get debug info we may not pass --debug at all to the command. Same kind of case we already have in this extension where we dynamically create the list of options that will be passed to the command

vscode-viva/src/services/actions/CliActions.ts

Lines 203 to 211 in c76154e

	const commandOptions: any = {};
	if (input.name) {
	commandOptions.name = input.name;
	}
	if (input.branch) {
	commandOptions.branchName = input.branch;
	}

Another thing I noticed is that when entering debug mode, many outputs are directed to stderr. Most of these outputs are not actual errors, but since they fill stderr, there are validations in the code that treat any output in stderr as an error, preventing the flow from continuing. This happens, for example, during the deploy stage.

This I did not figure out when prototyping this issue. Sorry for that.
CLI for Microsoft 365 have many configs https://pnp.github.io/cli-microsoft365/user-guide/configuring-cli
And one of it is errorOutput which allows to define if errors should be written to stdout or stderr. We could use that and set the config to sprint all errors to stdout instead. But this is kinda tricky as this setting may also modify the config of CLI for M365 someone might have already installed on the local machine outside of SPFx Toolkit.
So to sum up it is an option we may use but not the most (as of now) secure way. I will need to think about that 🤔.
Another way is we may just avoid error handling in SPFx Toolkit when debug setting is set 🤔, we are trying to debug SPFx Toolkit to get more error info right? This setting is suppose to show errors to try to get more info about a problem that might occur in SPFx Toolkit. This does make sense right

[DevPio]

The issue is that after enabling the debug flag and then removing it, the responses in debug mode seem to persist. I followed the approach you suggested in the code. I believe we could go ahead with your suggestion to disable error validation during debugging. However, the problem seems to be that there's some form of caching happening. After entering and exiting debug mode, even when the flag is no longer passed, the debug responses still appear.

[Adam-it]

@DevPio do you have this on some branch on your fork? Could I have a check at the code?

[DevPio]

Yes, I have this on a branch of my fork. You can check the code here: issue-282 branch.

[Adam-it]

@DevPio I had a check on that but TBH I have no idea why it behaves like this 😅. I did some experimenting but didn't find any work around it and I am checking why CLI actually always returns debug info as soon as we pass debug only once. I will try to do a bit deeper dive on this one next week