compiler: support method operations

[josephjclark]

A small fix in the compiler to recognise http.get() as an operation, like get()

This is needed to support the new http namespace in common, see OpenFn/adaptors#692

Discussion

Is this reasonable? Is this going to break everything?

It's fine.

To date, we have assumed that any top level function call, eg, fn(), is an operation call. And as a result it gets relocated into the exports array.

export default [fn()]`

Up to today, any method calls will be left alone. Which may or may not work depending on what you're trying to do.

http.get(www)

Where get is the old non-operation common.http.get.

That probably won't work though, because the get wil be issued before the runtime calls the operation pipeline. It'll all be out of order.

Now, because I'm recognising method calls as operations, I'll do this:

export default [http.get(www)]

If http.get is an operation, this will work. If it's not, well, it shouldn't be at the top of your code, should it? It shoudl be in an fn block. We do say that top level statements should be Operations (it's true, see the last line of the Job Writing Guide )

[stuartc]

There's a few console.logs that need to be taken out, assuming you know they are there.

The change looks good to me. But it does add a small barrier (or consideration) to taking member expressions to the next level (like non operation calls), but we're not there yet. We'd eventually have to know more about where these functions come from.

That's the only thing I thought was worth bringing up. Anyhoo, nice one!

[josephjclark]

@stuartc yeah so this would be a non-operation method call which you can do today:

dateFns.format(blah)

But that has to be nested inside an operation callback anyway. You can't just run that at the top of the script. Or at least you shouldn't.

Interestingly, this should be totally legal at the top of the job (it's actually a pattern I'd like to encourage)

const today = dateFns.format(new Date())

Let me add a test to check it

[josephjclark]

@stuartc And thank you for pointing out the logs! I'd missed them