Bridge.global "cannot read property <PROPERTY> of undefined"

[SirUppyPancakes]

Consider this Deck.NET example:
https://deck.net/c573f345024a1b1cf1331cb5b1608d4d

When calling a static, generic method located in another class, we have the option to use using static to avoid having to name the class, and we have the option to omit the generic type argument if the compiler can infer it.

When doing either of these things (or both of them), Bridge passes the type using Bridge.global.<TYPE> rather than just <TYPE>. I honestly have no idea what this means, since I am not aware of the internals of Bridge itself, but this causes a problem when the type does not exist on Bridge.global.

In my case, when using Retyped.electron, I pass the Retyped.electron.Electron.BrowserWindow type to a function like this, and when using Retyped.electron, there is not a member Bridge.global.Electron as is expected by the generated code, which causes the error:
Cannot read property 'BrowserWindow' of undefined

To see this in action, you can:

1. Download and extract the official Bridge Electron Sample: https://github.com/bridgedotnet/Widg...ive/master.zip
2. Run yarn install and then yarn start inside of the dist folder to make sure the app is running correctly
3. Then, close the app and open the dist/App.js file
4. Navigate to the CreateSplashScreen function and a line of code console.log(Object.keys(Bridge.global)); right before return splash;
5. Run the app again using yarn start
6. In the console, you will see that Bridge.global does not contain an Electron key

For now, I will workaround this issue by explicitly naming the generic argument and class name when calling these functions with Retyped types, but it would be nice to know if this is a bug or something that I am doing wrong in my own code when it comes to using Retyped.

[fabricio.murta]

Hello, your introduction here seems to support my thought about using using static instead of just using.

For your steps to reproduce the issue, directly editing a Bridge built file is not going to keep the sanity the compiler does in the code built, so the way you suggest to reproduce the issue is not really something that Bridge can support (as it can simply have no control over it).

Maybe if you rebuild the widgetoko project actually using the BrowsrWindow reference, you'll get working code you can base in (and understand what really does happen when you want to use it).

Hope this helps!

[SirUppyPancakes]

I agree that editing the JS is not a great way to reproduce the issue.

I have created an issue on GitHub with a minimal reproduction sample showing the issue in full: https://github.com/bridgedotnet/Bridge/issues/3736

Hopefully we can get to the bottom of it.

Thanks for spending time to look into this issue :)