Allow inline Lambda function definitions

[trilom]

Feature Proposal

Description

1. What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
   For some very simple lambda functions, such as CustomResources, it would be very useful to be able to define our function code in line. This way I can reduce footprint of infrastructure from 2 files (serverless.yml and function code file) to 1 file (serverless.yml with function code defined inline).

Here is an example of a similar enhancement defined in SAM for the same use case.

1. Optional: If there is additional config how would it look
   Here is an example of the usage.

service: custom-resource

provider:
  name: aws
  runtime: python3.7

functions:
  crFunction:
    handler: handler.handler
    code: |
        print('Here')


resources:
  Outputs:
    crFunction:
      Value: !GetAtt CrFunction.Arn
      Export:
        Name: "CrFunction"

plugins:
  - serverless-python-requirements

[Lokesh-Jawale]

I will like to work on this feature. @medikoo can you assign this to me?

Considered points for inline code for lambda function:

• Supported languages : python and node.js
• For the Handler property of lambda function, the first part of the handler identifier must be index. For example, index.handler.
• code size limit : 4mb
• For JSON, you must escape quotes and special characters such as newline (\n) with a backslash.

Below is the configuration for providing inlineCode to the lambda function.
The relation to its generated cloud formation template will be
cfTemplate:

Code:
    ZipFile: |
        print("Hello World!")

serverless config

functions:
  sayHello:
    handler: sayhello.handler
    code:
        inlineCode: |
            print("Hello World!")

[medikoo]

@Lokesh-Jawale let's leave it to plugin authors. It looks as invasive feature for which demand is very low, so I don't think it should land as part of a core.

Only issues with help wanted or good first issue tag are open for implementation (or spec discussion, see details in issue)