Allowing to use config values from a local context

[martinlingstuyl]

Currently all config is set globally. But what if you want to run a cli script with a specific set or configuration values within a project?

Instead of changing global config values all the time, we could allow the CLI to save config keys to a local setup (in m365rc.json)

For example:

m365 cli config set --key showSpinner --value false --local

Kind of like how Git does it.

This would allow you to push your configuration settings to a repo / share them with collegues / publish them to Azure Functions without needing to set any config value in the Function itself. You could extend the use to m365 setup as well:

m365 setup --scripting --local

Implementation

Add the following option to all relevant commands:

Option	Description
--local	When specifying this flag, the CLI will save/retrieve configuration values from the local context, the m365rc.json file in the current directory.

When checking for the value of a config key, the CLI will first check if the config key exists in the m365rc.json file, if not it will check the global setting.

Commands to update

• [ ] m365 cli config set
• [ ] m365 cli config get
• [ ] m365 cli config reset
• [ ] m365 cli config list
• [ ] m365 setup

[waldekmastykarz]

I like the idea. Is --local the name of the config switch in git? If not, then we could consider using --workspace instead, which aligns with VSCode. If git uses --local, then it makes sense to follow it.

[martinlingstuyl]

I like the idea. Is --local the name of the config switch in git? If not, then we could consider using --workspace instead, which aligns with VSCode. If git uses --local, then it makes sense to follow it.

In git you have:

• --system (systemwide settings)
• --global (global settings current user)
• --local (local settings in repo)

You typically use one of those flags, but it is also possible to use commands without flags:

• git config -l will show config values from ALL stores
• git config user.email '1@1.com' will update only the local config value
• git config --get user.email will get only the local config value

[martinlingstuyl]

Feedback @pnp/cli-for-microsoft-365-maintainers?

[Jwaegebaert]

I'm a big fan of this idea. My vote would go to using the --local option

[Adam-it]

Feedback @pnp/cli-for-microsoft-365-maintainers?

sorry I thought adding the 💖 was good enough 😉. For me it is and awesome idea and I don't actually have anything constructive to add other than 🚢 it --local seems good for me 👍 Great suggestion @martinlingstuyl

[martinlingstuyl]

Ok, so there's one thing to discuss:

If we use cli config list/get without --local, will we only work with the global store? Or will we get values from both stores?

Would we need a --global switch as well?

We could keep it simple and only work with the local store if we use --local.

[Adam-it]

yes. I would say global as default. Otherwise if someone uses --local then show the local config

[arjunumenon]

Very nice idea Martin. Loved the concept of --local settings. With you on that.

If we use cli config list/get without --local, will we only work with the global store? Or will we get values from both stores?

IMO we will just show one of the store and not both. IF needed, we can enhance it later with another flag something like --both which will show both. But for now, let us stick with one. For which settings - From a logical point of view, listing local would make more sense especially when the command is executed from the scope of the workspace.

[martinlingstuyl]

Well, I think it would also make sense to list every config key that applies, by default. At least that's how git does it, and it feels logical as well.

In that case, when setting a config key you would have to use either --global or --local.

[martinlingstuyl]

Let's get this opened up as it is. We can always add --global later if we see fit.

[Adam-it]

Let's get this opened up as it is. We can always add --global later if we see fit.

Totally forgot about this one and seems like an amazing feature. Let's 🚀