Cli-microsoft365: Naming convention for site collection commands

Created on 8 Dec 2017  路  7Comments  路  Source: pnp/cli-microsoft365

What do you think would be the logical naming convention for working with site collections in the CLI?

_Today, we have classic and modern sites. While they're both site collections, you work with them differently (different API, parameters and shape). In PnP PowerShell there are two sets of cmdlets: PnPTenantSite for classic sites and PnPSite for modern sites. What would be the logical naming convention to use in the CLI?_

  1. spo site <action> for modern and spo site classic <action> for classic sites (since modern sites are likely the way forward it would be better to not include _modern_ in the command name, and instead explicitly denote _classic_ sites)
  2. spo modernsite <action> and spo classicsite <action>
  3. spo site modern <action> and spo site classic <action> to explicitly denote type of site you want to be working with
  4. spo site <action> --type Modern|Classic for both classic and modern. Distinction between classic in modern is done inside each command. This would introduce higher complexity of all commands because they would have to handle two types of sites, including validating required options which are different depending on the type of site you're working with. Preferably we shouldn't choose this approach but maybe you have good arguments for doing it.

Any other naming conventions? Which one has your preference and why?
@VelinGeorgiev @estruyf @andrewconnell @wictorwilen

question

Most helpful comment

Correct... I think to go in line with what most CLIs do I'd expect to see something more like option 4:

spo site list --type classic
spo site list --type modern
# the following is the same as the modern option above
spo site list

All 7 comments

Option 1 : spo site <action> for modern and spo site classic <action> for classic sites.

I vote for #1 as well

Option 4 makes most sense to me with 鈥攖ype Modern being the default.

Why? Most CLI commands only have non-parameterized arguments as details on the command. To me, the type of a site is a switch, not details on the command, so it doesn鈥檛 make sense to put it as one of the arguments like option 1.

With that being said, I could live with option 1.

@andrewconnell just to double check if we're talking about the same:

In 1) commands would look as follows:

spo site add --title <title> --description [description] ...
spo site list
spo site classic add --title <title> --description [description] ...
spo site classic list

The only command that accepts a non-parametrized argument is spo connect <url>. I realize it might have been confusing of me denoting the command verb as <action> in the examples in the initial question. My bad.

Correct... I think to go in line with what most CLIs do I'd expect to see something more like option 4:

spo site list --type classic
spo site list --type modern
# the following is the same as the modern option above
spo site list

I like the simplicity, but I'm concerned with the implementation and maintenance complexity it brings. We'd need to wrap the whole body of validation and command action in a big if..then..else block because the implementation for either type of site is 100% different. What's also confusing for example are the expected values for parameters like WebTemplate: where for classic site you would specify for example STS#0 to get all team sites, but for modern sites you'd specify 64 to get modern team sites.

I took a closer look at the APIs that we have to use to work with sites in SharePoint and it seems there are too many differences between managing classic and modern sites. Both types of sites have different parameters and in some cases the same parameters even have different allowed values. Supporting both types of sites in one command would be challenging but explaining how the commands work in the help and which arguments are required when would be even harder. With that, let's go with 1) for now. If anything changes in SharePoint and its APIs we can always revise and merge support for both sites in one command.

Thanks for your opinions everyone, much appreciated! 馃憤

Was this page helpful?
0 / 5 - 0 ratings