fix: type getVariableValue helper

[adamviktora]

Closes #790, #630

I had to add some new helpers to simplify proper type checking.

[wise-king-sullyman]

If we're having to cast the return values of getAttributeValue in mods now I feel like there's something not right going on.

I don't want to spam this comment out so echo this same thing for the below files where we're casting the return value.

[adamviktora]

Here the casting is done because the actual selectableActions prop on CardHeader accepts only an object (CardHeaderSelectableActionsObject), so consumers shouldn't be able to pass anything else. I added a comment to make it clear.

The getAttributeValue should ultimately get to the ObjectExpression, or return undefined (e.g. if it was an Identifier imported from another file) in which case we don't do the fix

[adamviktora]

But yeah on many other places, the casting was done due to the lack of typing of the getAttributeValue helper

[wise-king-sullyman]

Great work on this so far! But I feel like for an issue focused on improving our typing we probably don't want to be adding a bunch of type casting if it can at all be avoided.

[wise-king-sullyman]

Great changes 🚀

I'm still not loving that we're having to make assertions about the return value pretty much everywhere we're using the helper now though. I'm not sure what can be done about that.... but I feel like there should be something.

Will do a little poking at this and probably come back with an approval after I can't find anything I like more.

[adamviktora]

Yeah, I don't love it either, but I think there is not a way of doing it without the type assertion.

In most cases it is being used as a way of telling the rule what type will the prop of the PatternFly react component accept.

So for example if we expect a variant value of an enum or string:
ToolbarItemVariant | 'bulk-select' | 'overflow-menu' | 'pagination' | ... we have to cast it to a string or a MemberExpression.

Another approach we could use instead of casting could be that we pass the type we expect to get back as an argument to the getAttributeValue, but we would have to probably cast anyway at some point e.g. to distinguish between an enum and a string.

In some cases the casting seems unnecessary (as Property), VSCode even doesn't mark it read, but ESLint doesn't like it.

[wise-king-sullyman]

Could we convert all of the return values into a standardized format (i.e. an object with a value field that holds the actual value and a type field that states what it is or something like that) so that the returned object is always consistent, then we can handle the return value in the mod based on the type field?