Fix process.env._HANDLER undefined

[franciscocpg]

Fixes #22

[azurelogic]

Can you confirm that this works when there are multiple functions and the target function isn't the first one?

[franciscocpg]

Yes, I'll do it tomorrow.

Also I'm going to try with serverless-offline plugin.

[franciscocpg]

@azurelogic
You were totally right about multiple functions.

So the best approach I found was to inject process.env._HANDLER just like AWS is doing on its environments.

Maybe @HyperBrain could give a quick look here too?

[HyperBrain]

Isn't this.options already the processed option object given to the plugin? If that's the case using this.options would decouple the implementation from Serverless internals.

[franciscocpg]

Yeap.

But there is a little difference.
If I call sls invoke local --function some-function:

this.options {
  "function": "some-function"
}
this.serverless.processedInput.options {
  "commands": [
    "invoke",
    "local"
  ],
  "options": {
    "function": "some-function"
  }
}

And If I call sls invoke local -f some-function:

this.options {
  "f": "some-function"
}
this.serverless.processedInput.options {
  "commands": [
    "invoke",
    "local"
  ],
  "options": {
    "f": "some-function",
    "function": "some-function"
  }
}

So using this.serverless.processedInput.options we always have the function key.

In any case I could also do something like this:

const invokedFunction = functions[this.options.f || this.options.function]

What do you think?

[HyperBrain]

Hmmm... That's strange also serverless-webpack uses this.options.function throughout the whole implementation. I was quite sure that the pluginManager would populate the long version in any case (regardless if you specify -f or --function). At least that was the handling for a long time.
However, the const invokedFunction = ... looks good otherwise.

[franciscocpg]

@HyperBrain
You're right.

I was calling JSON.stringify inside the plugin constructor.

But if I call it later then the results are:

"options": {
    "f": "some-function",
    "function": "some-function"
  }

It looks like serverless normalize it somehow, but I didn't take a deep look why this is happening.

So it's safe to use this.options.function as long as you are not using this in the plugin constructor.

[HyperBrain]

The reason why it is not yet normalized in the constructor is, that Serverless first loads the plugins and then starts the lifecycles of the invoked command. One of Serverless' lifecycle steps is the normalization (most likely in validate), but that can only be run as soon as Serverless knows the command (and thus the supported options, declared in the command structure).
So the same is true for any plugin - resolved and initialized properties (like options) are only available within the hooks, but not the constructor.

[franciscocpg]

Oh, I see.

Thanks for the explanation @HyperBrain

[HyperBrain]

In general, I think for the invoke local case, this would work (although it should be tested thoroughly first).

[franciscocpg]

@azurelogic
I think the PR is ready for review now.

[franciscocpg]

Any news here?

[ghost]

Waiting for this PR to be merged..