* add S3BatchEvent
* rename S3BatchEventResponseResultCodes
* linting
* s3VersionId is nullable
* add types for S3BatchHandler
* linting
* refactor S3Batch type names to conform to standard
* linting
* linting
* uppercase custom in client context
per the aws docs
```clientContext – (mobile apps) Client context provided to the Lambda invoker by the client application.
client.installation_id
client.app_title
client.app_version_name
client.app_version_code
client.app_package_name
env.platform_version
env.platform
env.make
env.model
env.locale
Custom – Custom values set by the mobile application.```
We have been using the upper case value with no problems so i assume the docs are correct here.
* Update aws-lambda-tests.ts
* [aws-lambda] Keys should be optional inside CloudFrontHeaders
According to the AWS documentation, it is optional to specify a `key` for each header value, but the type declaration is currently requiring this to be specified unnecessarily.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-response
> - `key` (optional) is the case-sensitive name of the header as it appears in an HTTP request; for example, `accept` or `host`.
> - If you do not include the header key portion of the key-value pair, Lambda@Edge will automatically insert a header key using the header name that you provide. Regardless of how you've formatted the header name, the header key that is inserted automatically will be formatted with initial capitalization for each part, separated by hyphens (-).
>
> For example, you can add a header like the following, without a header key: `'content-type': [{ value: 'text/html;charset=UTF-8' }]`. In this example, Lambda@Edge creates the following header key: `Content-Type`.
By making this property optional, one is able to write:
```ts
import { CloudFrontHeaders } from 'aws-lambda';
const headers: CloudFrontHeaders = {
'content-type': [{ value: 'text/plain '}],
};
```
... instead of having to repeat the header name like:
```ts
import { CloudFrontHeaders } from 'aws-lambda';
const headers: CloudFrontHeaders = {
'content-type': [{ key: 'content-type', value: 'text/plain '}],
};
```
* Update test
Setting a header without specifying the key should not raise a TypeScript compiler error.
* Revert "Update test"
This reverts commit 088653e362e6f0a152f54e9b5694bb778b072354.
* Add test for AWSLambda.CloudFrontHeaders with and without explicit keys
* Add the additional types for the usage of Application Load Balancer
* Change the long name "Application Load Balancer" to shorter one "ALB"
* Add ALBCallback for the completeness of the communication with the ALB
* Add Firehose to aws-lambda
* Add one more link for reference
* Change some interface names, remove irrelevant S3 interface, add special callback
* Fix tests
* Add: NotAction, NotResource, Principal, NotPrincipal
* Implement some of the conditional logic
- e.g., Action or NotAction is required
- however, mutual exclusivity is not implemented (hard to do in Typescript)
* Allow >1 statement per PolicyDocument
No tests added for the new types yet, I'll get on that tomorrow.
Motivation
---
The connection between the trigger event and the result types can be
confusing sometimes - for example `CloudFormationCustomResourceResponse`
is *not* returned from the lambda, but instead should be sent to the
*Request `ResponseUrl`. This PR tries to help by providing pre-baked
`Handler` types for each of the triggers (that have types already).
There's also a few niggles with naming and the handler signature that
have been bothering me for a while.
Changes
---
This PR:
- Adds defaulted generic parameters to the existing `Handler` and
`Callback` types. This increases the minimum TS version to 2.3.
- Makes the `callback` parameter to `Handler`s "required" - this
probably originally was meant to represent the Node 0.10 runtime,
which did not pass a callback parameter, but that is no longer
selectable when creating or editing a Lambda and makes the normal,
recommended usage harder. In case anyone is confused, this doesn't
break any code: it is required to be provided when being called, your
handlers don't need to declare it. I'm not removing the legacy node 0.10
runtime methods `context.done()` etc., since they still work.
- In the spirit of #21874, make the default result type for
`Handler`, `Callback` `any`, since the only requirement is
that it be `JSON.stringify()`able, and there are things like
`.toJSON()`, etc. so there is no meaningful type restriction
here.
- Revert the definition changes of #22588, which changed the `Handler`
result types to `void | Promise<void>`, which is misleading: Lambda
will not accept or wait for a promise result (it by default waits
for the node event loop to empty). This is not a breaking change for
code that does return promises, since a `void` result type is
compatible with any result type, even with strict function types.
(Which is why the tests still pass.)
- Adds `FooHandler` and `FooCallback` types for all `FooEvent`s and
`FooResult`s, where possible - sometimes these don't match up.
- Renamed, with aliases to the old name, various types to align them: in
particular `ProxyResult` -> `APIGatewayProxyResult`.
- `CloudFrontResult` (not the same type as `CloudFrontResponse`!)
was missing for some reason.
