[BUG] Expression Parsing: Parens in Ternaries Cause Function Call instead of Order of Operations / Grouping when following a String

[MattRogish]

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When I'm using Expressions in a Press Action or a Trigger, the paren processing is inconsistent.

Examples:
This works:

foo = 1
bar = "home"
foo == -1 ? "0" : (bar == "home" ? "0" : bar)

This does not:

foo = 1
bar = "home"
(foo == -1) ? "0" : (bar == "home" ? "0" : bar)

Internal/CustomVariables: Error: Unsupported function "undefined", in expression: "foo = 1
bar = "home"
(foo == -1) ? "0" : (bar == "home" ? "0" : bar)"

But this works:

bar = "home"
foo = 1
(foo == -1) ? "0" : (bar == "home" ? "0" : bar)

This does not work:

"hi"
(1 == 0) ? true : false

This works:

1
(1 == 0) ? true : false

The second example should parse correctly. I assume it must think "{string}" is a function name?

Steps To Reproduce

1. Go to a place where you are working with an expression
2. Type "(1==0) ? true : false"
3. It works!
4. Add a string before that line, either an assignment (foo="bar") or just "bar".
5. It doesn't work.

Expected Behavior

I would expect lines after a string to parse correctly.

Environment (please complete the following information)

- OS: MacOS 15.1.1
- Browser: Safari 18.1.1
- Companion Version: 3.4.3

Additional context

No response

[Julusian]

Initially I agreed with you that this behaviour is weird, but upon looking into it, this is how js behaves.
while the language of our expressions isn't exactly js, the parser we use is built to parse js so trying to avoid this situation is going to be very hard to do, and will likely result in a lot of effort over time to keep the workaround working.

I need to think on this some more to figure out if this is something we should support, or if I want to call this behaviour 'expected'

As a workaround, you could add a semicolon to your expression to force the parser to interpret it as separate statements:

"hi";
(1 == 0) ? true : false

or

"hi"
;(1 == 0) ? true : false

[Julusian]

A note for myself when revisiting this:

Maybe this could be resolved with an after-token hook which looks for a CallExpression where the open parenthesis is the first token on a new line? I'm not sure if the parser gives out enough info about context to detect this