Create new config to allow for consistent generated output ordering

[anniej42]

When running the generator two times in a row, the output is inconsistently sorted and creates a large git diff. When I add a new query for example, I'd like it to be easier to review the new generated types and functions before merging.

Describe the solution you'd like
A new config flag that allows for sorting the output. This might mean the generator will take a few more seconds to run, but since this is not happening at build time that works for me.

Describe alternatives you've considered
We've considered running the generator during the build and adding the generated file to .gitignore, but since the file is infrequently changed we'd prefer to manually review the diff during PRs.

[vhenzl]

This would be great! The output reordering every time I change my schema is bugging me a lot.

@dotansimha What do you think about adding sort config option for typescript plugin and using lexicographicSortSchema in the same way as you did for schema-ast in #5034?

[dotansimha]

I'm totally fine with that, but I think it should be in graphlq-tools loaders, and not in codegen. Because we need to do that after loading the schema. Codegen should offer flexibility to disable that feature (for large schemas).

[vhenzl]

Do you mean that schema argument received by a plugin would be already sorted? Or in other words, the sort option would be global for the whole codegen, it wouldn't be on a plugin level? It would probably work for my use case, however, I'm not sure what the benefit would be. It seems to be limiting. Let's say I would have a plugin that requires schema in the original order (for whatever it's doing) and I wanted the output of another plugin to be ordered, then I wouldn't be able to use them together (if I got a correct idea how it would work).

But I'm now familiar with graphql-tools and how its loaders work, so I'm afraid I can't help with it. I came back here for another reason.

I have patched @graphl-codegen/typescript locally in my project to use lexicographicSortSchema() and I have discovered that the function is dependant on system locale and can produce different order on different machines: graphql/graphql-js#2869

If my proposal to add support for locales to lexicographicSortSchema() gets accepted and is implemented in graphql then would be good if the sort option here (and graphql-tools) was boolean | string. true would enable sorting with the default locale and a string value would enable sorting with that value as locale.

[dotansimha]

@ardatan please take a look, should be simple to add to graphql-tools.

[vladinator1000]

We could also store a hash of the input in a comment in the generated file and use that to skip regenerating the schema if nothing changed?

[dotansimha]

We could also store a hash of the input in a comment in the generated file and use that to skip regenerating the schema if nothing changed?

Not sure, since we support many forms of loading, so it might cause issues in other areas (loading from git / url / external service).

[amaster507]

Any update on this? I would love to have consistent generated output files. I believe it is because when querying the schema it is returned in an object, and that object is not always sorted in the same way, so this generation script bases the output on whatever the order of that object was. There should be an option (or even default) to order this object to produce the same output every time.

Maybe there are some parts running asynchronously that return in the order they complete and write to file on order of completion which may vary. If so, then an option to run those parts synchronously would also be helpful. Creating some of my own generation scripts based off from GraphQL introspection and have come across this in my own code.

[ardatan]

@amaster507 I don't think relying on object's key order is a good idea in JavaScript but I am not sure about other languages. Even if we decide to have this feature, this will need a considerably big refactor on our loaders, schema mergers and visitor implementations. If anyone wants to do it, we'd like to accept PRs or recommendations at least.

To me, generated files shouldn't be part of git repo and ignored using .gitignore to prevent any diffs since the functionality is same independently from the order of the content.

[amaster507]

@ardatan, in my example, I need to order my object parameters, and wrote a script to order by the name of the child object. Again, I don't know the inner workings of this script, but I understand some of the complexity and the issue at hand of implementing this.

To me, generated files shouldn't be part of git repo and ignored using .gitignore to prevent any diffs since the functionality is same independently from the order of the content.

I guess this just varies on the use case. In my projects using graphql-codegen so far, I am generating on push to git if schema file changes. I guess it could be part of install/build/start script, but doing it on push ensures that the files that I have locally generated match identically to the files pushed to the server for the types/hooks/queries.