feat!: introduce declarative function signatures

[matthewrobertson]

This commit introduces an API that allows developers to explicitly register their functions against the framework so that they can declaratively configure the signature type in their application source code:

import * as functions from '@google-cloud/functions-framework';

functions.http('helloHttp', (req, res) => {
  res.send('Hello, http!');
});

functions.cloudevent('helloCloudEvent', (cloudevent) => {
  console.log('Hello, CloudEvent!');
});

When functions are registered using this API, the configured signature types take precedence over the --signature-type flag and SIGNATURE_TYPE environment variables.

When initialized the functions framework:

1. Loads the js module specified via the --source flag or FUNCTION_SOURCE env var
2. Checks if a function has been explicitly registered with the name matching the target name specified var the --target flag or FUNCTION_TARGET env var
3. If a function was not found in step 2, it looks for a named export from the --source module that matches the target name specified var the --target flag or FUNCTION_TARGET env var

[grant]

Great, thanks for the PR! I've left review and comments.

• Have we thought of the design of the interface a bit more? We might want to change the developer interface of the function register.
• Could we have a more detailed PR description? What are the user-facing changes, and what is the newly exposed interface? What if developers mix their existing functions with declarative functions?
• We probably want to include documentation changes. That can be in this PR or a following PR.

[grant]

nit: comment

[matthewrobertson]

This interface isn't exported. It is a private implementation detail of this module that is pretty self explanatory. I prefer not to add comments for these types of things.

[grant]

I don't think we defined the contract/interface yet.

But this implementation seems to assume that a single functionName can only map to 1 signature type and 1 userFunction.

Is that right and is that subject to change?

[matthewrobertson]

That's right, and I don't think it is subject to change. I can't imagine a use case that would motivate more flexibility. I was even considering adding validation logic that throws an exception if a function with the same name is registered more than once.

[grant]

lgtm :)

[grant]

Optional: Since we're adding a 3rd param, we might want to use an object rather than ordered list.

export async function getUserFunction({
  codeLocation,
  functionTarget,
  signatureType,
} ... )

That way, we could destructure when calling / using this function.