I think this brings back an issue that was solved in the past w.r.t. arrays inside variants: #429.
Now if you add a variant like:

type SomeVariant @variant {
  listOfStrings: [String]
}

The output type is:

type SomeVariant {
  listOfStrings: String
}

Which is suboptimal.

Probably what you want to look for instead is fixing the withTsTypeAndDecorator function so that it returns BigInt in case the f.type is BigInt, and [BigInt] in case f.isArray() && f.type === 'BigInt'. I'm just guessing that something like this will work, but there is probaby a better way to express it in the code.

This is probably a bit more complex, since for BigNumbers normally the @NumericField warthog decorator is used.
The simplest solution I can think of is:

• If f.type is BigInt (but is not array) render it with @NumericField decorator (just like in this PR)
• If it's both BigInt and an array - throw an error saying it's not supported (unless you find an easy way to add support for this case)
• Otherwise render field the "old way" (so we preserve arrays of Strings, Ints etc. inside variants)

I looked at the model.ts.mst template file for reference and turns out that, it uses two separate decorators(array, scalar) for Scalar & Array fields, For testing purposes, I tried the same approach in the variant template file also.

This approach fixed the problem of no array support inside the variant. All of the integration tests also passed after introducing this change, do you think this approach will work? OR does it also introduces some unknown problems?

So I found 2 issues with this approach:

• src/modules/variants/variants.model.ts(441,4): error TS2304: Cannot find name 'CustomField'. during warthog codegen step in the Joystream monorepo
• Something I overlooked before: It seems like after this change some variants that previously didn't have a WhereInput (like GeographicalAreaCountry), now have this type generated, although it's probably not a big issue.

However I decided to test the straightforward solution, in which I just added BigInt import from @joystream/warthog in variants.mst and in the constants.ts I changed numeric.gqlType to BigInt.

This solution doesn't seem to have any unwanted side-effects and I also ran a few tests in Joystream monorepo with thoses changes and they all passed.

Additionally I introduced a test someStuff field in CategoryStatusArchived of type [BigInt!] and tested a few other BigInt fields inside variants through a query:

The solution appears to work correctly even for very high numbers (ie. 1000000000000000000000000000000 inside TransactionalStatusBuyNow.

What do you think?

Changes compared to current PR: Lezek123@2d1425b

However I decided to test the straightforward solution, in which I just added BigInt import from @joystream/warthog in variants.mst and in the constants.ts I changed numeric.gqlType to BigInt.

I agree this is much simpler solution, I have implemented this way. Thanks for evaluating all options 🙏