fix: AccessMember.evaluate should always return undefined for non-existing members #795

[nenadvicentic]

Fix for issue the #795

[bigopon]

Thanks @nenadvicentic , this is probably the most uncomfortable issue I had with v1 behavior. While I agree we wont want to randomly return null/undefined, i dont think we can just change the behavior without an optin mechanism. In v2 we have the opportunity to rectify all this without any issues but v1 will need some effort.

[nenadvicentic]

@bigopon I get what your concern is, but I think this edge case is very rare, therefore we are fixing a glitch, not chaning the behaviour.

On top of that, it's very unstable edge case. It occurs only when parent object is null and we are making strict undefined or null check on a direct property of that object. For parent to be null, it has to be asigned by application (code or API call).

But more importantly, the moment end-user sets any other child property of null parent via data binding, Aurelia asignes new object to that parent. In that moment my missing property turns from null to undefined. It's unpredictable behaviour that developer has to shield against . I cannot see any use-case where someone actually relly on such glitch.

In addition, I run all 1795 already existing unit tests after applying this change. Everything was green, despite my change.

Btw, there is 2nd pull request where test runner is working with Node 22.

[nenadvicentic]

@bigopon Let me express myself in a programmers language... :)

To work around this glitch, I have to relax my checks of parent.property. From:

parent?.property === undefined

to:

parent?.property === undefined || parent?.property === null

I coudn't have used:

parent?.property === null

because property turns into undefined when parent is not null object any more.

So, framework constraining parent?.property to always be undefined instead of unpredicable undefined | null, won't break any developer code.