Add cmdlet prefix

[michevnew]

As discussed briefly the other day on the call, you should consider adding an unique prefix to all the cmdlets. This will not only make them easier to identify with the module, but avoid clashes with existing cmdlets. Prime examples being Get-User and Get-Group - both of these are heavily used in Exchange/Exchange Online PowerShell. And since support for Exchange management tasks in the Graph is still non-existent, it's very likely that people will use both the ExO cmdlets and the Graph module in the same PS session.

Considering the sheer number of cmdlets in the module, you're bound to have other duplicates as well.

[bschlintz]

Completely agree.

Adding a prefix to the module will...

• Make it easier to share scripts in a consistent manner
• Avoid confusion by requiring folks who aren't as familiar with Import-Module using -Prefix parameter
• Be consistent with other PowerShell modules such as "Verb-AzureRM", "Verb-SPO", "Verb-PowerApps", etc.

Perhaps a short acronym like "MSG" and "MSGBeta", short for Microsoft Graph and Microsoft Graph Beta, would be unique-enough to avoid conflicts and still be easy to type.

[darrelmiller]

We have received this feedback from a few people, however for the moment, we are continuing to recommend that people use the -prefix option of Import-Module if they want to add a unique prefix to the cmdLets.

We understand there are pros and cons to this approach. However, PowerShell has introduced a feature to specifically avoid namespace clashes and rather than do a land grab on a prefix and hope no-one else ever uses it, we are going to push towards using the built in capability.

[chrisgardnersage]

We have received this feedback from a few people, however for the moment, we are continuing to recommend that people use the -prefix option of Import-Module if they want to add a unique prefix to the cmdLets.

We understand there are pros and cons to this approach. However, PowerShell has introduced a feature to specifically avoid namespace clashes and rather than do a land grab on a prefix and hope no-one else ever uses it, we are going to push towards using the built in capability.

The likelihood of someone else using Msg or something for their prefix is much much lower than someone having a Get-User cmdlet/function. At the very least you should specify a default prefix in the manifest so that you don't have to update the command definitions themselves.

The fact this clashes with existing modules produced by MSFT should be enough to require a prefix, future authors will deal with the coming up with their own prefix but those other commands were there first (and should probably have their own prefixes as well) and therefore it's up to you to prefix your commands to prevent clashes for existing users, especially users who might want to trial these and run them side by side.

The Import-Module -Prefix approach isn't a great suggestion, it's little known by most PowerShell users, especially the average admin who's looking to use this module, and therefore should only be recommended should someone come out with a module with the same default prefix (there are a few I've seen). We really don't want a repeat of the Get-VM issues people have when having Hyper-V and VMWare installed side by side.

[Shoisk]

Completely agree with this. There's so many potential conflicts that could easily be avoided.

we are going to push towards using the built in capability

Manifests support a prefix, so that too is a built in capability I would assume? It seems arbitrary not to do it, when most other MSFT modules have done it recently. Sure, most of the clashes here are because some modules do not have prefixes, but we can't really fix the mistakes of the past, only make sure we don't mess up the future. Using Import-Module -Prefix is generally unhelpful if you're seeking help from the community aswell. It'd be a lot easier to

1. Share scripts
2. Get help from the PS slack / discord / reddit / whatever else exists

And probably more, if everyone has the same naming convention for these cmdlets, it's a mess to help people and to use scripts shared by others if they don't fit the same naming convention. Imagine a team using several shared scripts that utilize this module, and having written a few of their own. They'll have an internal naming standard for the prefix on this module, but anything they import they'll have to either just live with the fact that it doesn't use the same naming convention, or change it throughout the script so it does fit internal standards.
That seems like unnecessary work that could easily be avoided.

[colinrippeyfinarne]

I would suggest that the team behind this effort make contact with the Power Platform team who developed that technology's Powershell module. The first release had commandlets such as Get-App and the team received (a tad harsh IMHO) feedback to "please change the commandlets to be unique".

The team quickly pivoted to use a more specific nomenclature and none of us batted an eyelid, we were all very happy to move on with the new commandlet names even though they were far more verbose.

As for using Import-Module -Prefix I cannot remember the last time I added Import-Module to any of my scripts, modern Powershell really doesn't need it does it. I really think about the -Prefix feature to be used to help with any "internal name clashes" I might have with my own and/or 3rd party modules, not a feature that I'd have to use with a Microsoft module.

Finally as mentioned above, we'll (hopefully) see this module get widely adopted and used, this will no doubt give rise to blog posts, stackoverflow answers with sample scripts - but we'll quickly end up with adding disclaimers to every post with "for the following scripts to work please use Import-Module -Prefix XYZ".

[kilasuit]

@darrelmiller lets chat at Ignite (I know you mentioned you wanted to anyway) but please lets use a Prefix that's defined at the module manifest level to keep everyone happy particularly as just like @chrisgardnersage mentioned we have had many different historical issues because of a lack of prefix being added to cmdlets/functions being exported from a module.

The fact you also stated for the moment reads to me that you'd be open to taking this feedback onboard / possibly accepting a PR implementing it in future.

But again please please take on the feedback of those above

However this comment confuses me

However, PowerShell has introduced a feature to specifically avoid namespace clashes

The only feature I can think of (knowing PowerShell as well as I do) that you could mean is to fully module qualify a command like this
Microsoft.PowerShell.Management\Get-Item which breaks down to <modulename>\<cmdletName>
Which is an awful authoring and usability experience and should be avoided unless you really need that level of defensiveness (which you often really don't)

Like I said, happy to further discuss this in person this week at Ignite

[ToddKlindt]

I would also like to see a Prefix used in these cmdlets. I'm experiencing a conflict with the Sharegate cmdlets, who also refuses to use a Prefix. The only way I could get the the Graph Get-Group cmdlet to work was to completely uninstall the Sharegate product. That barrier is way too high for admins. I talked to @darrelmiller a bit about this at Ignite and after trying the -Prefix method I couldn't get that to work either. I'm not sure why the team is reluctant to add a prefix. Maybe if they explain that we could find a solution.
Not having a prefix is really killing my excitement for this module.

[ToddKlindt]

The other thing I'd like to add is that the current instruction for this module use the Install-Module cmdlet to install it, which does not support a Prefix parameter like Import-Module does. I'm not sure how to resolve the two sets of instructions, "Use Install-Module to get these cmdlets, but use Import-Module -Prefix to fix the collision."

[darrelmiller]

Hey folks. I really appreciate your input on this. There is a reason I didn't close this issue and just labeled it as a NotPlanned. :-)
The community has been 100% consistent on this feedback and I will be meeting with the team this week to reconsider our previous decision based on this feedback.