Type-graphql: {"nullable": true} option in field decorator of objects is not propagated from abstract mixin superclass to subclass when using mixin inheritance

[gae123]

Describe the bug
I am so bummed, I almost got mixin inheritance to work after I tackled many many details, but had to retreat because of this issue.

To Reproduce

• Create a typegraphql object U
• create an "isAbstract": true trait T that has a field f of type U wit {"nullable": true}. In my exact case
• Create an object T (or even U itself) that uses mixin inheritance to inherit T. This is done as shown in the examples like withId etc.

Expected behavior

• The generated GQL should show the field as f, it shows it as f! and of course this causes all kinds of issues.
• I confirmed that another field with was a Date in T did not have that issue
• I confirmed that if I made f a field of T the "nullable" option in the decorator was honored.

Environment (please complete the following information):

• OS: Linux
• Node 10.19.0
• Package version "type-graphql": "0.17.1",
• TypeScript version 3.7.5

[MichalLytek]

@gae123
1) Please use the latest 0.18.0-beta.15 release
2) Please create a minimal reproducible code example - I can't compile f, T and U in my head 😜

[gae123]

@MichalLytek does type-graphql have a testing framework? If it does the best would be to try to add a test case there that fails and then when there is a fix, it should succeed.

[MichalLytek]

Of course you can create a new test file with your use case and a failing test case to show what is the problem 😉

[gae123]

@MichalLytek a testing framework is part of the build system of a project, if you have one, pls point me to the README to understand how to contribute to it when I find the time.

If you do not you should stop everything else and do so, this stuff is too complicated not to automatically run regression tests on every change. You will be fixing/improving one thing while breaking another and you have a hard time accepting any PR from others. Let alone when you change version of typescript etc.

[MichalLytek]

@gae123 Have you at least check the files in the repository?
I can see a big tests folder there! 😱

to understand how to contribute to it when I find the time

It's a standard Jest setup, nothing to explain.
There was plenty of PR from external contributors that has managed to create proper tests:
https://github.com/MichalLytek/type-graphql/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+no%3Aassignee

You have two options:
1) Create a repository with a minimal reproducible code example.
2) Create a pull request with a failing test case that reproduce the issue.

Otherwise, I'm gonna close this issue as invalid.

[gae123]

This is a very valid issue, you should not close a valid issue just because a user does not have the time to give you a reproducible case. Other users might run into it. I will try to find time but I am not sure when.

[MichalLytek]

This is a very valid issue

I understand that, but for me this issue looks like:

• "This is not working! When I want to make it working, it throws an error!"
• "What is not working? Can you create a reproduction code example or a failing test case?"
• "I don't have the time to give you a reproducible case! And you cannot close a valid issue because other users might run into it!"

So yes, not properly reported issue in invalid and will be closed as I can't fix the issue if I don't know what is the real problem and you don't have time to make a proper report.

If you find some time to write a failing test case or create a repository with reproducible code example and a proper bug description, please open a new issue.

Closing this one 🔒

[gae123]

Whatever makes you feel good @MichalLytek but nobody succeeds in open source pooping on its users. Appreciate any little feedback they can afford to give you, don't be arrogant.

This is a valid issue with a descent description