Inconsistent client generation on Windows vs Mac

[pm7y]

Product

Strawberry Shake

Version

latest

Link to minimal reproduction

https://github.com/pm7y/StrawberryShakeBugRepro

Steps to reproduce

• Open the solution and generate the client on both windows and mac
• Inspect the client cs file that it generated.

What is expected?

In the IProjectFragment interface, the interface type of the Manager property should be the same type as that on Mac and Windows.

What is actually happening?

It's not, and this is a huge problem because it results in differently named and incompatible interfaces depending on which OS you use to compile the solution. On Mac it is IProjectSearchQuery_ProjectSearch_Manager and on Windows it is IProjectQuery_ProjectSearch_Manager

This is happening because the GeneratorHelpers.GetGraphQLDocuments method in src/StrawberryShake/Tooling/src/dotnet-graphql/GeneratorHelpers.cs does not order the files, and the order returned by default is different on Mac vs Windows. Since there are two queries that share a fragment, the name is composed of which ever query is processed first.

Mac Order

• GraphDocuments\01_ProjectQuery.graphql (therefore "ProjectQuery" is used in the type name)
• GraphDocuments\02_ProjectSearchQuery.graphql
• GraphDocuments\ProjectFragment.graphql

Windows Order

• GraphDocuments/ProjectFragment.graphql
• GraphDocuments/02_ProjectSearchQuery.graphql (therefore "ProjectSearchQuery" is used in the type name)
• GraphDocuments/01_ProjectQuery.graphql

Possible Solutions

• The code should name the fragment types independently and not include name parts from any queries i.e. it could be IProjectFragment_Manager and not IProjectQuery_ProjectSearch_Manager
• Ensure the file order is consistent (and therefore the type creation and naming is consistent), I believe the code in GetGraphQLDocuments needs to order the files found as follows OrderBy(s => s, StringComparer.InvariantCulture).

Any fix would likely need to be opted in via a configuration setting to avoid breaking behavioural change.

Relevant log output

No response

Additional context

No response

[jackawatts]

Have experienced the same issue with macOS and Windows and then later on as part of the build pipeline.

It likely doesn't matter which flavour is chosen, so long as it is consistent across both platforms.

[pm7y]

Looks like this might be related to (or a dup of) #6873