* added type and handler for CodeBuild Cloudwatch State event
* added type and handler for CodeBuild Cloudwatch event
* added test for codebuild cloudwatch event
* extended definitions block
* added SECRETS_MANAGER as environment variable type
* removed handlers
* removed unnecessary general codebuild types
* CodeBuildCloudWatchStateEvent extends EventBridgeEvent and added CodeBuildCloudWatchStateHandler
* added general type strArrayOrUndefined for tests
* added tests for CodeBuildCloudWatchStateHandler
* [aws-lambda] tweaks to APIGatewayProxyEventV2 interface
* [aws-lambda] tweaks to response type of API Gateway v2
* [aws-lambda] tweaks to APIGatewayProxyResultV2<T>
* [aws-lambda] Add support for payload format version 2.0 of API Gateway proxy event
* [aws-lambda] minor fix
* [aws-lambda] prettier fix
* [aws-lambda] minor fixes to test
* [aws-lambda] Added support for EventBridge triggers
* Changed cloudwatch-events to use eventbridge types as AWS extended cloudwatch-events to create EventBridge
* Added multi type handler example to eventbrige test
* Added requestId member on all CloudFrontEvent types
The requestId member is defined on all origin/viewer requests/responses, it is described here : https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html
There is one example for each request/response and they all have a cf.config.requestId.
Added new requests examples in tests in order to have all 4 types available
* Fix lint issue with consecutive empty lines
* Fix missing spaces
* [aws-lambda] Deprecate CustomAuthorizer*, new APIGateway*Authorizer*
Noticed this testing #42419.
When integrating a custom authorizer, you actually have two options,
creating a token or a request authorizer, which changes what payload
you will get. You nearly certainly know which you will be called with!
Just deprecating the old version as it's kinda broken in a way thats
hard to fix without breaking someone, but we want to guide devs to the
new version.
It is possible to fix the existing type by adding a bunch of
`foo?: never` fields to each alternative so existing accesses don't,
error but this makes things more complex, and confusing for the common
case.
Other ideas welcome!
* [aws-lambda] Add api-gateway authorizer parameters.
Fixes#34069, #42418
Ended up a bit messy, might be a bit much.
* [aws-lambda] Bump minimum typescript to 3.0
Required to fix failing $ExpectError in tests.
Surely nobody is still using pre-3.0?
* [aws-lambda] Enforcea API Gateway authorizer context narrowing
And implement the changes that API gateway does on the proxy request context for it.
Also rename TAuthorizer to TAuthorizerContext to be more clear that they should be the same type across both authorizer and proxy.
Some cleanups and fixes for names.
* [aws-lambda] Some docs, split up index.d.ts into multiple files.
Documents handler type and conventions for adding triggers more
explicitly. The same index.d.ts docs should explain the thinking for the
new layout convention.
No changes to the type tests in this first commit, to show that the tests
still passs, and because I think they deserve more attention (and I need
lunch right now).
Most event structures have little to no changes other than re-ordering or removing
inaccurately copy/pasted comments in a case or two.
Loses history, but github doesn't support rename history anyway, and
it's even more ugly to get git to track file splits even for local
usage. Apologies for the huge diff.
* [aws-lambda] Split tests to per-service files, add contributor README.md
Updates most of the files to a consistent style.
* Make ExpectError locations same for TS 3.8
Error locations changed for some object literals in TS 3.8. This breaks
tests that use ExpectError since the ExpectError needs to be closer to
the actual error.
To fix this, I merged a lot of multi-line object literals into one-line
literals.
* remove stray edit
* 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
