💡 [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 https://github.com/pnp/vscode-viva/blob/b66d97f889c913a416518ec0b4e426c373cfb2f9/src/services/CliCommandExecuter.ts#L25

[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 https://github.com/pnp/vscode-viva/blob/c76154ea024bb116a9fcde51a858376c87887c81/src/services/actions/CliActions.ts#L203-L211

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

[Adam-it]

@Saurabh7019, @nicodecleyre, I believe this feature has little demand at the moment and provides little value to the end user. This feature was an idea to provide a way to help us debug problems with SPFx Toolkit, but TBH, when compared to other PnP repos/products, the amount of bugs is very small, and from the feedback I got, usually the problems usually do not require to debug the response of CLI command and if it does we may always just run SPFx Toolkit locally and debug the output ourselves.

I vote for closing this as not planned What do you think?

[Saurabh7019]

This was a great idea.

let's say you are logging in using an app that doesn't have the required permissions. In that case, the Toolkit won't display the tenant app catalog URL or other associated tree items. The current output doesn't provide any clue why that's happening. If we could see the CLI debug output, we would know the reason. So having this option would really help troubleshoot such scenarios.

That said, if it is too much work for something that is not needed by many, we can lower the priority or even close it.

[Adam-it]

ok in this case lets leave this open and in progress @DevPio are you still engaged on this issue and would like to continue working on it?