Consistent order of definitions in Schema::as_schema_language output

[nikis05]

Definitions in SDL created by Schema::as_schema_language appear to be sorted semi randomly. We are using this method to print SDL to a file, and this behaviour makes changes to the schema harder to review, and to navigate the file in general.

Proposed solution

Sort definitions in the following order:

1. Query type
2. Mutation type, if any
3. Subscription type, if any
4. All other types, sorted alphabetically

Additional context

Currently, the order persists between compilations as long as there are no changes to schema, but a change to one item commonly results in multiple unrelated items changing their position.

[scriptonist]

I can take a look at this and submit a patch if there are no objections.

[cloudsftp]

Could you kindly provide some code to reproduce this @nikis05 ?

I would like to start contributing to this amazing project and there seems to be no progress on this issue.

[michael-groble]

So this branch is an initial take at how to support this.

It adds the functionality to graphql-parser instead of here. All it does is sort the definitions so it could easily be moved here if the ordering is intended to be "juniper-specific".

Two sort orders are implemented, name-then-type (similar to the ordering in the github public schema) or type-then-name (examples of both types were added to the tests).

I believe the request is slightly different from the name-then-type option currently implemented. I think what is being requested is that we first look for the types referenced in the schema, print those three types first, then sort the remaining.

Would love to get a little feedback on the following before flushing this out completely:

• whether to provide base ordering capabilities in graphql-parser or not. alternatives are:
  • control insertion order in GraphQLParserTranslator.translate_schema
  • control output order by sorting the generated document as this code does
• spec out the sort order support in a little more detail
  • add a new ordering for putting the three "special" types first
  • value of keeping the type-then-name one or not
  • opinions on sort order for extensions and items with directives (the branch takes a stab at that)
  • whether sorting within any types are needed

[LegNeato]

I think output ordering is more flexible, no? It also makes it so lib users who aren't outputting to a file don't need to pay the overhead of sorting. What is easier in the code?

I think sort order should have some higher-level config. We don't need to do all variants, but whatever default we do will be "wrong" for a large portion of the population. I think there are probably only a few major options and it would be good to support the obvious ones.

Thoughts @tyranron ?

[tyranron]

@michael-groble thank you for taking time on this and providing the possible solution.

I took your "type-then-name" approach and implementation in #1237 to ship it in the upcoming 0.16 release as a quick and working solution for this problem.

I suggest you to make a PR with your solution into graphql-parse library. And once it's released, we can switch to the one there.