Fix TypeScript codegen for list input field types

[ryan-m-walker]

Currently the TypeScript generated code for list input field types does not correctly generate accurate types. If the list is nullable and the item is nullable it does not create an array item for the list type. It also creates a union with the array type and the type in the array which is not accurate since GraphQL will not accept that. This can be fixed by using the same logic that the renderFieldType method uses (which works correctly) for lists for renderInputFieldType

Given the following schema input:

input TestInput {
  testField1: [String]
  testField2: [String!]
  testField3: [String]!
  testField4: [String!]!
}

the following TypeScript code is generated:

 export interface TestInput {
  testField1?: String | null[] | String | null | null // // String and null are rendered twice, and String[] is not an option
  testField2?: String[] | String | null // `String` type should not be allowed for this field
  testField3: Array<String | null> // works as would expect
  testField4: Array<String> // works as would expect
}

After this PR the following code will be generated instead:

export interface TestInput {
  testField1?: Array<String | null> | null
  testField2?: Array<String> | null
  testField3: Array<String | null>
  testField4: Array<String>
}

[Urigo]

Thank you for the fix.

In the last few months, since the transition of many libraries under The Guild's leadership, We've reviewed and released many improvements and versions to graphql-cli, graphql-config and graphql-import.

We've reviewed graphql-binding, had many meetings with current users and engaged the community also through the roadmap issue.

What we've found is that the new GraphQL Mesh library is covering not only all the current capabilities of GraphQL Binding, but also the future ideas that were introduced in the original GraphQL Binding blog post and haven't come to life yet.

And the best thing - GraphQL Mesh gives you all those capabilities, even if your source is not a GraphQL service at all!
it can be GraphQL, OpenAPI/Swagger, gRPC, SQL or any other source!
And of course you can even merge all those sources into a single SDK.

Just like GraphQL Binding, you get a fully typed SDK (thanks to the protocols SDKs and the GraphQL Code Generator), but from any source, and that SDK can run anywhere, as a connector or as a full blown gateway.
And you can share your own "Mesh Modules" (which you would probably call "your own binding") and our community already created many of those!
Also, we decided to simply expose regular GraphQL, so you can choose how to consume it using all the awesome fluent client SDKs out there.

If you think that we've missed anything from GraphQL Binding that is not supported in a better way in GraphQL Mesh, please let us know!