Awesome! We'll review it in the coming days as we're preparing for a release. Thank you!

Sorry I didn't catch it earlier, but what's exactly the difference between using field and properties? It seems they both end up in the $select query so why should we introduce another option?

Hi @waldekmastykarz
You are right. Both field and properties will end up in $select query.
However from the caller's point of view, they are different parameters.

You're right. Would renaming fields to properties be sufficient or would it still be confusing to end-users? Is there perhaps another word that's would clarify both use cases?

@pnp/cli-for-microsoft-365-maintainers what do you think?

Sorry I didn't catch it earlier, but what's exactly the difference between using field and properties? It seems they both end up in the $select query so why should we introduce another option?

I don't see the value in making the change, introducing another option would just cause confusion. Renaming the field option to something more suitable would be a breaking change, if we were to do this I would prefer the term properties over fields.

Would renaming fields to properties be worth considering for v4 or is cosmetics?

I think properties is the more appropriate terminology.

I am also in an opinion to rename it to properties rather than fields. It makes more consistent with the generic SharePoint terminologies and I am in opinion that the end users would be able to connect it well with properties

In that case, I'd suggest that we close this PR and the related issue and open a new issue scheduled for the v4 version of CLI that will introduce the breaking change of renaming fields to properties.