cli-microsoft365: UnhandledPromiseRejectionWarning: ParserError: Unexpected token type: Colon, value: :

Sounds good to me

I think the suggested by Garry is what I as SharePoint developer 😄 would expect to see as options. --queryText makes sense in absence of the reserved for JMESPath --query. --enableFql is a flag that clearly identifies what we are after. I assume this flag will be used by users already familiar with the search apis and they would look for such flag since it is similar to the APIs. To Sebastian’s point of new query language, I do not think we should bother with this at the moment simply because this is not even on the roadmap and might never be introduced.

OK, so the issue is that with the introduction of support for JMESPath queries, we used the query option, which was previously used for specifying the search query in the spo search command. So instead the command processing your input as a search argument, it treats it as a JMESPath query. To fix this, we’ll need to rename the either option to avoid them colliding. Sorry for the trouble.

@sebastianrogers as a workaround for now, please use the short -q instead of --query.

To minimize the impact of this change (one command vs. all commands), I’d suggest renaming --query in spo search to --searchQuery. The short -q could stay as-is.

To add my thoughts to this, I have been accustomed to the notion of enabling FQL when searching against SharePoint using the REST API, this is in part due to the way that the SharePoint Search REST API has been implemented over the years.

The Search REST API uses KQL by default, most likely due to FAST historically being an add-on to SharePoint Search rather than part of the core Search service, so was added later to the API, this resulted in having to explicitly state that FQL should be used by passing the enableFql property in the query-string to make it explicit that FQL should be used rather than KQL.

GET http://_server_/_api/search/query?querytext='sharepoint'&enablefql=true

Source: https://docs.microsoft.com/en-us/sharepoint/dev/general-development/sharepoint-search-rest-api-overview#enablefql

It’s also worth noting that out of the box web parts have also gone with the KQL approach first historically and this is also true with the way that the PnP Modern Search web parts have been implemented, so again something that people will be accustomed to.

My opinion is that we should follow the REST API, which I think is the most common and widely understood implementation, this provides a solution that would change --query to --queryText solving the conflict with JMESPath, and provide an --enableFql switch for explicitly defining that the query should use FQL.

o365 spo search --queryText "IsDocument:1" --selectProperties "Path,Author,FileType" --enableFql

Not a problem, suggest you call it --kql to make it clear what sort of query to use