bug: using `null` or `undefined` as the `@Mock(() => result)` throws error about mockingbird HOT 9 OPEN

@arthurfiorette what version are you using? Can you try it with 3.0.0-rc.3?

from mockingbird.

Yes, it's been tested with a new integration test, look here: https://github.com/omermorad/mockingbird/blob/mockingbird%403.0.0-rc.3/packages/parser/test/integration/common/test-classes.ts, those are all actual classes that are being tested (simulates a real situation).

I belive I will release this in the next week, I almost have no time to breathe now because of the new startup I work for :)

from mockingbird.

Hello, Plumier developer here. I come here because I see that the error was related to the @plumier/reflect error.

We currently have some bugs fixed on our newest release v1.1.0, let me know if you having any further issues.

from mockingbird.

Sorry for the delay, I was traveling. Did you manage to reproduce this bug?

from mockingbird.

Keep on doing that, we need some fresh air sometimes :)
I didn't get to it yet, but until I will - if you have a chance to add a snippet it might be helpful!

from mockingbird.

Hey @omermorad, It's me again.

This bug is occurring when i use the T | null or T | undefined type.

class Test {
 @Mock(...)
 fine: string;

 @Mock(...)
 alsoFine?: string;

 @Mock(...)
 notFine: string | null;
 
 @Mock(...)
 alsoNotFine: string | undefined;
}

And that's because with a strict tsconfig, the decorator metadata emitted for these lines are different:

// With fine?: string;
tslib_1.__metadata("design:type", String)

// With notFine: string | null;
tslib_1.__metadata("design:type", Object)

Note that this only occurs with strict: true on the tsconfig.json.

This could be alright if it was trying automatically to find a mock value, but as it was manually specified (not this), I don't think that the metadata should be read and interpreted.

And when it needs to be interpreted, but the generated metadata is Object, it should emit a warning (not an error) or adapt itself like other decorators libraries do.

// type-graphql does manually the type

@Field(() => String) // <--
a: string;

I don't have time to create a 100% reproductible steps in the moment, but this should be sufficient...

from mockingbird.

Yep, 3.0.0-rc.3 works just fine!

from mockingbird.

But, is it safe to upgrade? If it is, you should create a stable release (3.0.0)...

from mockingbird.

@omermorad ?

from mockingbird.