m365 saved context

[Adam-it]

So like yesterday I had a discussion with a friend and he pointed out that in m365 all the time (for almost every command) we pass -u or --webUrl param, as opposed to PnP PowerShell were we don't have to do it 🤔. This of course is understandable as in PnP PowerShell we connect to a single site and by default work in the context of this site and in m365 CLI we just login to the tenant which connection persist, so we don't have to start with login in every time, which is cool 🙂, and in the end what we do is we usually have variables like $TeamSiteFor... which we just pass to every command.
What I was thinking (and maybe is a good idea or a completely stupid one 😋) is maybe in m365 CLI we could create something like an m365Context. So for example the user could create any kind of context (name it whatever he or she would like to), pass to the context any kind of parameters and then when some command is used and user does not specify the needed parameters CLI could first look if those were specified in the current context and if yes use them 🤔. What do you think? seems interesting ... or maybe my description is totally not clear 🤔.
ok... maybe I will try with some mocked code and comments 🙂

m365 context create --name 'context1' parameters '{ webUrl: https://someSiteUrl/Site/Site1 }' # here lets say we create a context name context1 and we pass any kind of params as json
m365 context create --name 'context2' parameters '{ webUrl: https://someSiteUrl/Site/Site2 }' # here we create anther context name context2
m365 context use --name 'context1' # here we define all commands from that point on we want to be done in context of context1
m365 spo list list # lets say we now want to get all lists within the specified site but we did not specify webUrl BUT since it was specified in context1 CLI uses webUrl from this context and gets all lists for site https://someSiteUrl/Site/Site1
m365 context use --name 'context2' # here we define all commands from that point on we want to be done with context2
m365 spo list list # now we also don't specify the webUrl but since w use context2 we get result for Site2, if the context would not have this parameter in context then we would get error

I hope the code example is more clear.. TBH for me it is 😅
Let me know what do you think 🙂?

[waldekmastykarz]

This is a very interesting idea! We could persist the context on disk and that way make it easy for future re-use. That way we could define a set of parameters that you can have ready in the background and whenever you run a command, we could expand them before running validation: a bit like a super-clipboard. When it comes to setting the context, we can make use of CLI's ability to support unknown arguments, so rather than using JSON and fiddling with escaping quotes we could say: m365 context set --name ctx1 --webUrl https://contoso.sharepoint.com/sites/site1 and the command would know how to handle webUrl as one of the options to persist on context with name ctx1.
Using a command like context list we could list available contexts, to delete a context we could offer context remove --name, with context get we'd return the current context (if any), and using a command like context reset, we could disable context for the time being, while not removing any context information from disk. We could persist the currently selected context in CLI's settings.

Since we wouldn't persist auth, we'd need to give it a thought if context is the right word, but the concept still applies and I like it A LOT! Thank you for bringing it up! 👏

[waldekmastykarz]

@plamber had a good point: if we store context on disk, then it could potentially affect scripts running in parallel in a different terminal session, which could have severe side-effects. Rather than persisting the context on disk, we should see if there is a way to store it in the context of a terminal session so that when the session is closed, there's nothing left and context doesn't spill beyond the current session. Apparently az CLI has something similar implemented and we should check out if we can learn anything from it as it runs similarly to our CLI.

[Adam-it]

that's totally understandable and true 👍. Maybe it could be and option to save 🤔 lets say by default it is stored in 'session' but when we create it with some param --save then it is stored in drive. TBH I feel this a bit like having NVM and different versions of npm's installed. Every script started just checks if it is using the correct npm 🤔. But I do agree this may create more confusion and problems so for starters lets go with the simplest option possible 🙂.
BTW thanks @plamber & @waldekmastykarz for thinking on this and considering it 👍

[waldekmastykarz]

nvm analogy is a good one. You have a default, but then you can change it per terminal session. Good balance! 👍

[Adam-it]

@pnp/cli-for-microsoft-365-maintainers 🤩 moving the discussion from private discussion back here 😉. It is still opened from back in the days I had this idea... what an old idea 👴 ... Lets try to make it happen 💪

[waldekmastykarz]

Shall we summarize what we discussed so far for everyone's benefit?

[Adam-it]

indeed we shall.... but TBH as I checked the description added in this discussion is already what we more or less also agreed internally 😉. I don't think we have anything more except a basic concept 😉. but ok:
To summarize the idea is to have a in CLI a kind of 'basket' (I call it context but we may name it whatever we want) to which we could pass any kind of key pair JSON with options and values we use in CLI commands. Like { "webUrl": "someSite", "listItemId": 1 }, no limitations. (of course user could also pass some completely abstract option we don't have, but I guess that is on the user responsibility to be precise). Then when we execute some CLI command without specifying some option to it (does not matter if required or not) and this option would be in the 'basket' (context) then CLI should automatically use that value for executing the command. I guess that all that is for now. Typical scenarios this would support would be a kind of helper for migrating between lists, sites, tenants etc. Also this might be helpful for scripts running in loop were we would like to keep all variables in one place and just pass context to the script 👍.
From technical point of view the current idea was to keep context as local json files (by default stored in the place where CLI is installed, in future maybe we could allow the user to specify the place as well).
As for commands for sure we need a command which will allow to add, delete, update the 'basket' (context) as well as list all currently saved contexts.
I think also one context may be 'in use' active at a time so we need some commands to enable and disable contexts.

Waiting for feedback 🤩😉

[waldekmastykarz]

To avoid making it overly complex, I'd suggest that we start with just one context:

1. We start with allowing storing context in a file in the current directory. We can use the existing .m365rc.json file that we already use for app * commands. We'll try to read context from this file before executing each command and apply the context information if available
2. Later, we add support for setting global context using the cli config set command

I'd suggest that we avoid naming contexts, because it would very quickly get complicated and make it hard to track which context is applied when.

[Adam-it]

that's good idea. Lets start with supporting one but not forget what we aim 👍

[Adam-it]

@pnp/cli-for-microsoft-365-maintainers any additional comments on this one? should we try to open an issue for it and try to challenge this with an implementation ? 😉`