Cli-microsoft365: New command: `cli config set`

[garrytrinder]

Usage

m365 cli config set [options]

Description

Update specific CLI setting with a new value

Options

| Option | Description |
| ----------------------- | ----------------------------------------- |
| -k, --key <key> | The setting to be updated |
| -v, --value <value> | The new value |

Additional Information

We currently don't provide a way to easily update CLI settings, for example, if a someone wants to use their own identity, we ask them to update two environment variables CLIMICROSOFT365_AADAPPID and CLIMICROSOFT365_TENANT, however it maybe beneficial to provide a command that makes this easier for users to set these settings to their own preference using the CLI and persisting these settings to disk, in a file stored in the users root directory e.g .cli-microsoft365, for convenience.

This command would also provide a future extensibility as we grow personalisation options.

m365 cli config set --key aadappid --value 506af689-32aa-46c8-afb5-972ebf9d218a
m365 cli config set --key tenantid --value e8954f17-a373-4b61-b54d-45c038fe3188

GitHub CLI implements a similar command, gh config set <key> <value>, for updating default settings to user preferences. Source: https://cli.github.com/manual/gh_config_set

[waldekmastykarz]

I love the idea! Shall we rename the command to m365 cli config set to make it clear what we're setting/getting?

[garrytrinder]

Happy to include config 👍🏻

In regards to persisting settings, should we create a new file in the home directory to store these values, something like .climicrosoft365?

[waldekmastykarz]

I think we already have the logic in place for the tokens file so we could reuse it for this config file as well.

[appieschot]

Sounds like a great plan!

[garrytrinder]

I think we already have the logic in place for the tokens file so we could reuse it for this config file as well.

Ok great, so lets reuse the .cli-m365-tokens.json file 👍

[waldekmastykarz]

@garrytrinder just to clarify: what I meant was that we have the logic to work with a custom file stored in the user's root folder, not that we should store settings in the same file. That said, we could do it, but then we should consider renaming the file since it no longer would be containing just the tokens.

[garrytrinder]

Apologies, I think I misread your comment and thank you for clearing this up.

It makes sense to have separate files, I'll update the spec.

[waldekmastykarz]

I've updated code samples in the issue with the new command name. 🚀

[michaelmaillot]

I can try to implement this command if it's ok for you 🙂

[waldekmastykarz]

~Before we start, @garrytrinder with the recent introduction of the --appId and --tenant options for the login command, is this command still necessary?~

No matter if we use it for appId and tenant which we mentioned initially, we can still use it for other things like automatically showing help when a command fails. Let's get it in @michaelmaillot.

I think the best way to persist config would be by using the configstore package which we already use indirectly through update-notifier, so that we don't introduce yet another dependency.

[michaelmaillot]

Ok, I'll try with that updated approach...! 😅

I've got a couple of questions:

• When / where should the config be loaded? In the cli\Cli.ts file or somewhere else?
• What is the best between
  
  
  
  • loading the configstore on a higher level of the CLI
  
  
  • loading it on the fly, when executing the cli config set command
  
  
• Should the configstore be initialized at first start with pre-configured properties?
• Which settings will we add (other than "always-show-help-on-error")?

[waldekmastykarz]

I think it's twofold: setting config and loading config. For the purpose of this command, loading config is out of scope. We could decide if we implement validation for checking config names, which allows for more flexibility, or if we validate the specified name and each time introduce a new setting, we'll also need to update the whitelist.

How does git handle it for example? My preference would be the first (no validation) but I'm curious how others see it @pnp/cli-for-microsoft-365-maintainers

[michaelmaillot]

AFAIK on the gh config set command, it only allows to set already defined properties : git_protocol, editor, prompt and pager.

So even if we let it free to configure for users, the CLI should own some keys to configure its usage, right?

[waldekmastykarz]

I see configuring the settings and actually using them in the CLI as two separate things. This command is meant to allow users to configure CLI settings, whatever these settings are. Making specific pieces of the CLI configurable based on users' preferences should be specced and implemented separately. If we want to introduce a validation of keys, then we'd need to know at least one or we won't be able to complete the implementation of this method.

[michaelmaillot]

We're agree on that point 😊

But I don't have any idea about key settings to start with...

[waldekmastykarz]

showHelpOnFailure which controls if we automatically show help when command fails or not

[michaelmaillot]

Just to be sure: can I start to work on it or should we wait for maintainers folks to give their feelings about it?

[waldekmastykarz]

We had the spec approved, so you can definitely start working on it. Appreciate your help! 👍