Skip to content

Releases: aws-powertools/powertools-lambda-typescript

v1.11.0

29 Jun 15:26
@github-actions github-actions
v1.11.0
71f1892
Compare
Choose a tag to compare
v1.11.0

Summary

In this release we are excited to announce the General Availability of the Parameters utility 🎉 After almost three months of beta period we consider the utility ready for production workloads and consider the API stable.

Parameters

The Parameters utility provides high-level functions to retrieve one or multiple parameter values from AWS Systems Manager Parameter Store, AWS Secrets Manager, AWS AppConfig, Amazon DynamoDB, or your own parameter store.

Key features

  • Retrieve one or multiple parameters from the underlying provider
  • Cache parameter values for a given amount of time (defaults to 5 seconds)
  • Transform parameter values from JSON or base64 encoded strings
  • Bring Your Own Parameter Store Provider
Fetching parameters from AWS SSM Parameter Store

To get started, install the library and the corresponding AWS SDK for JavaScript v3:

npm install @aws-lambda-powertools/parameters @aws-sdk/client-ssm

Next, review the IAM permissions attached to your AWS Lambda function and make sure you allow the actions detailed in the documentation of the utility.

You can retrieve a single parameter using the getParameter() high-level function.

import { getParameter } from '@aws-lambda-powertools/parameters/ssm';

export const handler = async (): Promise<void> => {
  // Retrieve a single parameter
  const parameter = await getParameter('/my/parameter');
  console.log(parameter);
};

For multiple parameters, you can use getParameters() to recursively fetch all parameters under a path:

import { getParameters } from '@aws-lambda-powertools/parameters/ssm';

export const handler = async (): Promise<void> => {
  /**
   * Retrieve multiple parameters from a path prefix recursively.
   * This returns an object with the parameter name as key
   */
  const parameters = await getParameters('/my/path/prefix');
  for (const [key, value] of Object.entries(parameters || {})) {
    console.log(`${key}: ${value}`);
  }
};

Alternatively, you can also fetch multiple parameters using their full name by using the getParametersByName() function.

Getting secrets from Amazon Secrets Manager

To get started, install the library and the corresponding AWS SDK for JavaScript v3:

npm install @aws-lambda-powertools/parameters @aws-sdk/client-secrets-manager

Next, review the IAM permissions attached to your AWS Lambda function and make sure you allow the actions detailed in the documentation of the utility.

You can fetch secrets stored in Secrets Manager using the getSecret() function:

import { getSecret } from '@aws-lambda-powertools/parameters/secrets';

export const handler = async (): Promise<void> => {
  // Retrieve a single secret
  const secret = await getSecret('my-secret');
  console.log(secret);
};
Fetching configs from AWS AppConfig

To get started, install the library and the corresponding AWS SDK for JavaScript v3:

npm install @aws-lambda-powertools/parameters @aws-sdk/client-appconfigdata

Next, review the IAM permissions attached to your AWS Lambda function and make sure you allow the actions detailed in the documentation of the utility.

You can fetch application configurations in AWS AppConfig using the getAppConfig() function:

import { getAppConfig } from '@aws-lambda-powertools/parameters/appconfig';

export const handler = async (): Promise<void> => {
  // Retrieve a configuration, latest version
  const config = await getAppConfig('my-configuration', {
    environment: 'my-env',
    application: 'my-app',
  });
  console.log(config);
};
Retrieving values from Amazon DynamoDB

To get started, install the library and the corresponding AWS SDK for JavaScript v3:

npm install @aws-lambda-powertools/parameters @aws-sdk/client-dynamodb @aws-sdk/util-dynamodb

Next, review the IAM permissions attached to your AWS Lambda function and make sure you allow the actions detailed in the documentation of the utility.

You can retrieve a single parameter from DynamoDB using the DynamoDBProvider.get() method:

import { DynamoDBProvider } from '@aws-lambda-powertools/parameters/dynamodb';

const dynamoDBProvider = new DynamoDBProvider({ tableName: 'my-table' });

export const handler = async (): Promise<void> => {
  // Retrieve a value from DynamoDB
  const value = await dynamoDBProvider.get('my-parameter');
  console.log(value);
};

For retrieving multiple parameters, you can use the DynamoDBProvider.getMultiple() method instead.

Learn More

If you want to learn more, check the post we have just published on the AWS Compute Blog: Retrieving parameters and secrets with Powertools for AWS Lambda (TypeScript)

Acknowledgements

A big thank you to all the people who contributed to this utility with PRs, questions, feedback, and bug reports.

Changes

🌟New features and non-breaking changes

  • feat(idempotency): preserve original error when wrapping into IdempotencyPersistenceLayerError (#1552) by @am29d

📜 Documentation updates

🔧 Maintenance

This release was made possible by the following contributors:

@am29d, @dreamorosi, @hjgraca and Release bot[bot]

Contributors

hjgraca, am29d, and dreamorosi
Assets 2
Loading

v1.10.0

23 Jun 14:33
@github-actions github-actions
v1.10.0
40b1b68
Compare
Choose a tag to compare
v1.10.0

Summary

This release brings the Release Candidate (RC) for the Parameters utility as well as a bug fix for the Metrics utility and improvements to the Middy middlewares of all three core utilities. Starting from this release we are also adding provenance and publish attestation to our packages, and we have a new documentation domain.

Parameters

Note
This release of the Parameters utility is expected to be the last release before the utility goes GA (General Availability) in the next one.

In this new version we have completed the work on the input and return types of all providers. Now, when retrieving a value the utility will modify its return type based on the intersection between the transform being applied and the actual data types returned by the AWS APIs.

For example, when retrieving a Secret from Amazon Secrets Manager, the default return type would be a string or undefined in case the value is not found. When applying a json transform however, the return type can be any JSON primitive that can be parsed by the JSON.parse() function.

getSecret

To support this feature we have added new types for JSON primitives and have applied them to all the Parameters providers.

Additionally, we have also finalized the exports for the utility that should be scoped and allow you to tree-shake all the providers that you are not using and avoid shipping unnecessary code.

Metrics

Prior to this release the Metrics utility allowed to add a number of data points greater than the current limit of 100 data points set by the EMF specification.

With this release we are releasing a fix that ensures that when a new data point is added, and the limit is reached, all the stored metrics are flushed right away.

If you are using Metrics in your workloads and are dealing with a large number of datapoints, we encourage to update to the latest version of the package at your earliest convenience.

Middy middlewares

As part of this release we have fully rolled out the cleanup hooks in all the Middy middlewares offered by Powertools for AWS.

This feature is intended for those who write their own custom middlewares, and specifically for those middlewares that might need to stop the whole execution flow and return a response immediately.

In these cases, to prevent data loss for data, you should make sure to call the cleanupMiddlewares() function before returning. In doing so all Powertools core utilities will make sure to flush any data they might have stored.

This function doesn't require you to know which or how many Powertools middlewares are in the Middy stack, and in case no other middleware has registered its cleanup function it will result in a no-op.

cleanupMiddlewares

📚 Additionally, we now have a page dedicated to Powertools for AWS on the Middy documentation where you can find information about its middlewares as well as best practices for users and middleware authors.

Provenance

Starting from this release, all the npm packages under the @aws-lambda-powertools/scope are published together with publish and provenance attestations (example transparency log and scorecard on npmjs.com below).

This allows you to publicly establish that our packages was built and published by us, which can increase your supply-chain security.

image

Click here to learn more about the definition of each attestation and how the feature works.

Governance

As you might have noticed, we have moved the project to a new GitHub Organization dedicated to Powertools for AWS Lambda (new name, who this?). The migration is still ongoing behind the scenes and we'll share more in the coming weeks.

With the new name, ✨ Powertools for AWS Lambda (TypeScript) ✨, we also have a new domain for our documentation: docs.powertools.aws.dev/lambda/typescript. Links to the previous domain (and repository) should be redirected for the most part, however if you are a content creator and have links to the project, we encourage you to update them if possible.

Finally, we have updated our public roadmap and our public Project Board, together with corresponding Milestones. This should give you visibility over the areas we plan on focusing for the rest of the year.

Acknowledgements

Congratulations to @kitsunde for landing your first merged PR, and special thanks to @am29d and @sthulb for making this release possible.

Changes

🌟New features and non-breaking changes

  • feat(metrics): publish metrics when other middlewares return early (#1546) by @dreamorosi
  • feat(tracer): close & restore segments when other middlewares return (#1545) by @dreamorosi
  • feat(logger): clear state when other middlewares return early (#1544) by @dreamorosi
  • feat(parameters): review types and exports (#1528) by @dreamorosi

📜 Documentation updates

🐛 Bug and hot fixes

  • fix(metrics): flush metrics when data points array reaches max size (#1548) by @dreamorosi
  • fix(docs/ci): change how versions and aliases are inserted into versions.json (#1549) by @sthulb
  • fix(idempotency): pass lambda context remaining time to save inprogress (#1540) by @am29d
  • fix(docs): aliases in versions.json (#1522) by @sthulb
  • fix(docs): upload versions.json (#1521) by @sthulb
  • fix: update reference in workflow (#1518) by @sthulb
  • fix(idempotency): skip persistence for optional idempotency key (#1507) by @am29d
  • fix(idempotency): record validation not using hash (#1502) by @dreamorosi
  • chore(docs): Fix docs upload to s3 (#1494) by @sthulb

🔧 Maintenance

This release was made possible by the following contributors:

@am29d, @dreamorosi, @kitsunde, @sthulb

Contributors

kitsunde, sthulb, and 3 other contributors
Assets 2
Loading

v1.9.0

09 Jun 17:58
@github-actions github-actions
v1.9.0
8d62a62
Compare
Choose a tag to compare
v1.9.0

Summary

This release includes the ability to modify and retrieve the log level at runtime in Logger, as well as the ability to know whether your AWS Lambda function invocation is being sampled by AWS X-Ray. The release also includes additional improvements to the types of the Parameters utility and the introduction of two deprecation notices for minor undocumented helper functions that will be removed in the next major release.

Logger

Starting with this release you can set the Logger level at runtime as well as retrieving the current level both in string (i.e. DEBUG) and numeric (i.e. 8) notations.

Prior to this version, you could only set the log level when creating a new Logger instance. There are however cases (see #1265) in which you might want to change the log level of an existing Logger instance at runtime.

To support this type of feature we have added three new methods to the Logger utility:

Set a new log level

The first one is the Logger.setLogLevel() method. This method accepts a string (both lower and uppercase) and sets the corresponding log level.

import { Logger } from '@aws-lambda-powertools/logger';

const logger = new Logger();

logger.setLogLevel('DEBUG');

If you pass invalid value, the method will throw an error.

Get current log level

The second one is Logger.getLevelName(), which returns the current log level as string:

import { Logger } from '@aws-lambda-powertools/logger';

const logger = new Logger();

logger.getLevelName(); // returns "INFO"

Get current log level number value

The third, and last one, is a new class property called level, which holds the numeric value of the current log level:

import { Logger } from '@aws-lambda-powertools/logger';

const logger = new Logger();

logger.level; // returns 12

Tracer

Thanks to @icholy's feature request and contribution we have added a new method to Tracer that allows you to know whether a specific Lambda invocation is being sampled in X-Ray or not.

The new Tracer.isTraceSampled() method reads the value of the _X_AMZN_TRACE_ID environment variable and returns a boolean value reflecting whether the function invocation is being traced or not.

You can use this value to further enrich your JSON-structured logs together with the existing Tracer.getRootXrayTraceId():

import { Logger } from '@aws-lambda-powertools/logger'; 
import { Tracer } from '@aws-lambda-powertools/tracer'; 

const tracer = new Tracer();
const logger = new Logger();

export const handler = async () => {
  try {  
    throw new Error('something went wrong');
  } catch (error) {
    logger.error('something went wrong', {
      trace_id: tracer.getRootXrayTraceId(),
      trace_sampled: tracer.isTraceSampled(),
      error,
   });

   throw error;
  }
};

Parameters

We continued the work started in the previous release and improved the return types for the Parameters utility by applying adaptive types to the SecretsProvider.

The new types use generics and modify the return type of the functions/methods based on the arguments passed to them or based on an explicitly set type.

For instance, if users pass transform: json, then we can assume that the return type should be an object (Record<K, V>). Conversely, if no transform or a binary (base64) transform is applied, the result will be a string.

import { getSecret } from '@aws-lambda-powertools/parameters/secrets';

const jsonValue = getSecret('my-secret', { transform: 'json' }); // type is `Record<string, unknown>`
const binaryValue = getSecret('my-other-secret', { transform: 'binary' }); // type is `string`

Finally, if the user doesn't specify any transform then, given that Amazon Secrets Manager is able to store both SecretString and SecretBinary data types, then we can only narrow down the return type to one of string or Uint8Array.

There are however also cases in which users might know more about the values they are retrieving than the compiler does, and for those instances this PR introduces the ability to specify the return type while using either the function or method like so:

import { getSecret } from '@aws-lambda-powertools/parameters/secrets';

const value = getSecret<number>('my-secret', { transform: 'json' });

In the example above the value constant will have type number, this is because the user has specified a type and so this will take precedence over any type-heuristic we do behind the scenes.

Deprecation Notices

We have started laying the groundwork for the next major release and as first item we have marked both the createLogger and createTracer helper functions as deprecated. Both functions were undocumented and were only used in tests, however since they were part of the exported modules we are marking them as deprecated and leaving them intact until the next major release.

If you are using them in your code, we encourage you to move to instantiating the utilities directly as we will remove these functions in the next major release:

-- import { createLogger } from '@aws-lambda-powertools/logger';
-- import { createTracer } from '@aws-lambda-powertools/tracer';
++ import { Logger } from '@aws-lambda-powertools/logger'; 
++ import { Tracer } from '@aws-lambda-powertools/tracer'; 

-- const logger = createLogger();
-- const tracer = createTracer();
++ const logger = new Logger();
++ const tracer = new Tracer();

Acknowledgements

Finally, a big thank you to both @icholy and @arnabrahman for landing their first merged PRs 🎉 🎉

Finally

Changes

🌟New features and non-breaking changes

  • feat(idempotency): idempotency middleware & types exports (#1487) by @dreamorosi
  • feat(idempotency): makeHandlerIdempotent middy middleware (#1474) by @dreamorosi
  • feat(idempotency): add package exports (#1483) by @dreamorosi
  • feat(logger): enhance log level handling (#1476) by @dreamorosi
  • feat(commons): add cleanupPowertools function (#1473) by @dreamorosi
  • feat(tracer): add isTraceSampled method (#1435) by @icholy
  • feat(idempotency): implement IdempotencyHandler (#1416) by @am29d
  • refactor(metrics): unit tests for Metrics are written to follow similar convention as Logger/Tracer (#1414) by @arnabrahman
  • feat(parameters): add adaptive types to SecretsProvider (#1411) by @dreamorosi

📜 Documentation updates

🔧 Maintenance

This release was made possible by the following contributors:

@am29d, @...

Read more

Contributors

rubenfonseca, sthulb, and 6 other contributors
Assets 2
Loading

v1.8.0

07 Apr 16:20
@github-actions github-actions
v1.8.0
8d8c585
Compare
Choose a tag to compare
v1.8.0

Summary

This release brings new features and improved types to the Parameters utility as well as two new features for Metrics and Loggers

Parameters

New configuration options

The Parameters utility allows you to configure caching and decryption behaviors via arguments passed to the utility functions or class methods. This allows you to configure the retrieval and lifecycle of parameter values in a granular way.

In some cases however you may want to configure function-wide settings so that all your values are decrypted or cached for a given amount of time.

Starting from this release you can do this via two new environment variables called POWERTOOLS_PARAMETERS_MAX_AGE and POWERTOOLS_PARAMETERS_SSM_DECRYPT.

When set, the POWERTOOLS_PARAMETERS_MAX_AGE environment variable instructs the Parameter utility to cache a given value for the specified duration, this applies to all providers supported today:

maxAge-params

Likewise, with the POWERTOOLS_PARAMETERS_SSM_DECRYPT environment variable you can configure the decryption behavior for all values retrieved from AWS Systems Manager Parameter Store:

decrypt-params

Note
Both new environment variables are used by Parameters only when the corresponding setting is not passed directly to the function/method. When a setting is used locally the environment variable value is discarded -i.e. getParameter('/my/value', { maxAge: 10 }); will override POWERTOOLS_PARAMETERS_MAX_AGE="100" since maxAge is passed directly to the function.

Thanks @mikebroberts's for suggesting the feature and for the early feedback on the new utility!

New types

As part of this release we are introducing new and improved types types for the getParameter(), getParameters(), and getParametersByName() functions as well as their class-based corespondents (i.e. SSMProvider.get(), etc.).

The new types use generics and modify the return type of the functions/methods based on the arguments passed to them or based on explicit type that you set.

For example, if you pass transform: 'json', then Parameters is smart enough to assume that the return type should be an object (Record<K, V>). On the other hand, if no transform is specified or a binary (base64) transform is applied, the Parameters utility will always return a string.

types

The new types work with both single and multiple values retrievals, with the only difference that in the case of multiple values the return type will always be a nested object.

There are however still cases in which you might know more about the values they you are retrieving than the compiler does. In those cases you can to specify a return type while using any of the SSM methods like so:

const value = getParameter<number>('my/param', { transform: 'json' });
// OR
const objValue = getParameters<Record<string, number>>('my/path', { transform: 'json' });

This will tell TypeScript that you want to use an explicit type and automatically set the return type to use it:

explicit-type

We hope that these new types will improve your developer experience when working with Parameters and we plan to bring similar types to all other providers in future releases.

Testing

As part of this release we have also added a new section to the Parameters docs dedicated to unit testing code that uses the utility. This section contains suggested patterns to test your code and use Jest spies and mocks with the Parameters utility.

To facilitate your testing efforts, the Parameters package now includes a new clearCaches() helper function that you can use to reset all the caches between tests:

clearCache

Fixes

In addition to the changes above, this release also includes a fix contributed by @karthikeyanjp that solves a build issue that affected the AppConfigProvider and that was caused by a wrong import. Thank you @karthikeyanjp for reporting the issue, for contributing a fix quickly, and congrats for your first PR merged in this project!

Logger

Starting from this release the Logger utility supports a new CRITICAL log level and a new critical() method to emit logs.

You can use this new log level when you want to configure Logger to emit only logs that are severe enough to require immediate attention or that could cause the application to fail. When logLevel is set to CRITICAL all other logs emitted with any other the other methods, including error(), will be suppressed and only logs emitted with critical() will be sent to stderr.

carbon-2

Thanks to this addition you can share existing CloudWatch Logs Insights queries or log group-metric filters across Powertools runtimes.

Thank you to @H1Gdev for sharing their use case and proposing this feature 👏

Metrics

When using the logMetrics() decorator or middleware the Metrics utility automatically flushes for you all the buffered application metrics at the end of a function invocation.

Additionally, you can pass an optional throwOnEmptyMetrics parameter to tell the Metrics utility to throw an error when metrics are being flushed but no application metric was present. This allows you to ensure that your application is emitting metrics that are important to your use case.

Starting from this release, even when throwOnEmptyMetrics is set to false, if no application metric is created during an invocation the Metrics utility will emit a warning log to inform you that metrics are being flushed with an empty buffer.

carbon

This new warning will help you detect potential missing metrics or even redundant usages of the logMetrics() decorator and middleware in your functions.

Changes

🌟New features and non-breaking changes

📜 Documentation updates

🐛 Bug and hot fixes

🔧 Maintenance

This release was made possible by the following contributors:

@am29d, @dreamorosi, @karthikeyanjp

Contributors

mikebroberts, am29d, and 3 other contributors
Assets 2
Loading

v1.7.0

20 Mar 21:00
@github-actions github-actions
v1.7.0
6c7bf23
Compare
Choose a tag to compare
v1.7.0

Summary

In this release we are excited to announce the first developer beta for the new Parameters utility 🎉. This new utility allows you to retrieve one or more parameter values from a range of AWS services, while also helping you reduce the amount of custom code needed to handle caching, transformations, and error handling.

The release also includes a new log level for Logger, support for high precision metrics in the Metrics utility, and a new behavior around missing segments in Tracer.

Parameters

Warning
This utility is currently released as beta developer preview and is intended strictly for feedback and testing purposes and not for production workloads. The version and all future versions tagged with the -beta suffix should be treated as not stable. Up until before the General Availability release we might introduce significant breaking changes and improvements in response to customers feedback.

The Parameters utility provides high-level functions to retrieve one or multiple parameter values from AWS Systems Manager Parameter Store, AWS Secrets Manager, AWS AppConfig, Amazon DynamoDB, or your own parameter store.

Key features

  • Retrieve one or multiple parameters from the underlying provider
  • Cache parameter values for a given amount of time (defaults to 5 seconds)
  • Transform parameter values from JSON or base64 encoded strings
  • Bring Your Own Parameter Store Provider

Getting started

To start testing the utility, install it from npm using the @aws-lambda-powertools/[email protected] alias.

In addition, you will need to add the AWS SDK client for the parameter store you are planning to use. The Parameters utility supports AWS SDK v3 for JavaScript only which allows the utility to be modular, and you to install only the SDK packages you need and keep your bundle size small:

  • SSM Parameters Store -> @aws-sdk/client-ssm
  • Secrets Manager -> @aws-sdk/client-secrets-manager
  • AppConfig -> @aws-sdk/client-appconfigdata
  • DynamoDB -> @aws-sdk/client-dynamodb @aws-sdk/util-dynamodb

Next, assign appropriate AWS Identity and Access Management (IAM) permissions to the Lambda function execution role of your Lambda function that allow retrieving parameters from the parameter store. You can see which permissions are needed for each action and store in the IAM Permissions section of the utility's docs.

Note
In the section below we will use Secrets Manager as store to showcase different features of the Parameters utility. The same features are available for all other providers, as well as some others unique to each store. If you are interested in another store, skip to the utility docs.

Retrieving a single secret

To retrieve an individual parameter, the Parameters utility provides the getSecret function:

carbon

Adjusting cache TTL

By default, the retrieved value will be cached in-memory for 5 seconds. This cached value is used for subsequent invocations of the Lambda function until it expires. If you want to keep the value around longer, the Parameters utility allows you to adjust the time-to-live (TTL) via the maxAge argument:

carbon-2

If instead you want to make sure that the latest value is always retrieved and cache is skipped, you can use the forceFetch option:

carbon

Decoding secrets stored in JSON or base64 format

If some of your secrets are stored in base64 or JSON, you can deserialize them via the Parameters utility’s transform argument:

carbon

Customizing the AWS SDK

In some cases, you might want to use your own custom AWS SDK to retrieve values. This is useful in those instances in which you want to configure specific parameters or if you want to apply tracing. To do so, you can use the provider class directly:

carbon-2

To learn more about all the features available for each provider, check the Parameters docs.

Logger

Due to popular demand, and thanks to @shdq contribution, in this release we are adding a new SILENT log level to Logger. This new log level provides a simple and efficient way to suppress all log messages without the need to modify your code.

carbon-2

When you set this log level, all log messages, regardless of their severity, will be silenced. This feature is useful when you want to have your code instrumented to produce logs, but due to some requirement or business decision, you prefer to not emit them.

Metrics

A few weeks ago Amazon CloudWatch announced support for high resolution metrics in structured logs (EMF). Thanks to @niko-achilles's contribution, the Metrics utility now allows you to pass an optional resolution parameter to the addMetric() method to create high resolution metrics.

carbon

High-resolution metrics are data with a granularity of one second and are very useful in several situations such as telemetry, time series, real-time incident management, and others. To learn more about the implications of this setting on your metrics, read here.

Tracer

The Tracer utility allows you to manage segments and annotate them. The segments are derived from the X-Ray Trace header present in the Lambda execution environment. Prior to this release, if Tracer wasn't able to obtain the current segment it would throw an error.

Starting from this release, after hearing from customer feedback, we have modified the behavior of Tracer to more closely align with the current behavior of X-Ray SDK for Node.js and instead log a warning when a segment is missing.

Special thanks to @danrivett for providing extensive feedback around this behavior and helping improve the project for all users.

Acknowledgements

Thank you to @shdq and @niko-achilles for your continued contributions to the project, and congrats to @PatriciaHeimfarth and @brnkrygs for landing your first merged PRs in Powertools!

Changes

🌟New features and non-breaking changes

  • refactor(tracer): log warning instead of throwing when segment is not found (#1370) by @dreamorosi
  • feat(metrics): support high resolution metrics (#1369) by @niko-achilles
  • feat(parameters): AppConfigProvider to return the last valid value when the API returns empty value on subsequent calls (#1365) by @brnkrygs
  • feat(logger): add silent log level to suppress the emission of all logs (#1347) by @shdq

📜 Documentation updates

  • docs(parameters): write utility readme update main one (#1280) by @dreamorosi
  • docs(parameters): add typedoc api docs (#1283) by @dreamorosi
  • chore(examples): fix cdk cleanup command (#1364) by @PatriciaHeimfarth

🔧 Maintenance

  • chore(parameters): add package to release process (#1377) by @dreamorosi
  • chore(ci): added lint-staged as pre-commit hook (#1360) by @dreamorosi
  • chore(ci): build api docs first so we can publish it in the next step (#1368) by @am29d
  • chore(examples): fix cdk cleanup command (#1364) by @PatriciaHeimfarth
  • chore(docs): updated layer info (#1358) by @dreamorosi

This release was made possible by the following contributors:

@PatriciaHeimfarth, @am29d, @brnkrygs, @dreamorosi, @niko-achilles, @shdq and Release bot[bot]

Contributors

shdq, am29d, and 5 other contributors
Assets 2
Loading

v1.6.0

02 Mar 17:29
@github-actions github-actions
v1.6.0
196ded7
Compare
Choose a tag to compare
v1.6.0

Summary

This minor release fixes some bugs on the Logger as well as bringing some improvements on how log levels are accepted and handled. As a part of the release we have also published our public Lambda Layers to 3 new AWS Regions.

Logger

The first of two bugs addressed was affecting functions using Logger together with the injectLambdaContext Middy middleware. When enabling both the clearState and logEvent flags, attributes attached to logs within the function's scope were not cleared properly. This caused values set during an invocation to appear in the event log emitted at the beginning of the next invocation. We have fixed the bug and revisited our unit and integration tests to prevent future regressions.

The second bug was instead related to the createChild method and caused children of a Logger instance to not inherit all attributes of their parents. We have fixed the issue, improved our unit tests around the feature, and clarified the documentation.

Finally, we have made the types of the logLevel construct option of Logger more strict, so that typos in the log level names can be caught at compile time rather than fail silently at runtime.

image

Lambda Layers

You can now use our Lambda Layers in three new AWS Regions: Spain (eu-south-2), Zurich (eu-central-2), and Asia Pacific (Melbourne) (ap-southeast-4). Find the full list of regional ARNs here.

With this release we can finally consider the roadmap item related to this topic complete 🚀.

Acknowledgments

A big thanks also to @Muthuveerappanv for getting their first PR merged into the repo, as well as @shdq and @niko-achilles for the contributions around Logger and documentation.

Finally as you can see from the full list of changes below, the team has been hard at work to bring you new utilities, so keep an eye on the next releases!

Changes

  • tests(logger): revisited integration tests (#1342) by @dreamorosi
  • tests(logger): revisit Logger unit tests (#1339) by @dreamorosi
  • tests(parameters): update package to run as part of e2e tests (#1318) by @dreamorosi
  • tests(parameters): integration tests for AppConfigProvider (#1287) by @dreamorosi
  • tests(parameters): integration tests for SSMProvider (#1257) by @dreamorosi
  • tests(parameters): added missing tests for DynamoDBProvider (#1285) by @dreamorosi
  • tests(parameters): add comments to SecretsProvider e2e test (#1282) by @am29d
  • tests(parameters): integration tests for SecretsProvider (#1263) by @am29d
  • build(deps): bump http-cache-semantics from 4.1.0 to 4.1.1 (#1270) by @dependabot
  • tests(parameters): end to end tests for DynamoDBProvider (#1244) by @dreamorosi

🌟New features and non-breaking changes

  • feat(logger): make loglevel types stricter (#1313) by @dreamorosi
  • feat(layers): add new regions (#1322) by @am29d
  • refactor(parameters): moved ssm resource creation to AwsCustomResource (#1319) by @dreamorosi
  • refactor(parameters): move table seeding into AwsCustomResource (#1317) by @dreamorosi
  • feat(idempotency): Add function wrapper and decorator (#1262) by @KevenFuentes9
  • feat(parameters): add support for custom AWS SDK v3 clients for providers (#1260) by @shdq

📜 Documentation updates

🐛 Bug and hot fixes

  • fix(logger): middleware stores initial persistent attributes correctly (#1329) by @dreamorosi
  • fix(parameters): handle base64/binaries in transformer (#1326) by @dreamorosi
  • fix(logger): fix a bug when child logger didn't get all the parent's attributes (#1267) by @shdq
  • fix(docs): logger bringYourOwnFormatter snippet (#1254) by @niko-achilles
  • fix(parameters): Tokenize attribute names in DynamoDBProvider (#1239) by @dreamorosi

🔧 Maintenance

This release was made possible by the following contributors:

@KevenFuentes9, @Muthuveerappanv, @am29d, @dreamorosi, @heitorlessa, @niko-achilles and @shdq

Contributors

shdq, am29d, and 6 other contributors
Assets 2
Loading

v1.5.1

13 Jan 14:50
@github-actions github-actions
v1.5.1
ed55e58
Compare
Choose a tag to compare
v1.5.1

Summary

This first release for 2023 updates the AWS Lambda runtimes officially supported by Powertools for TypeScript, as well as bug fixes.

Node.js 12 deprecation

With AWS Lambda deprecating the nodejs12.x runtime at the end of March this year, we have decided to drop support for the runtime as well. Node.js 12 has reached end-of-life a few months ago, so we recommend anyone still using this runtime to upgrade their functions to Node.js 14 or later.

Node.js 18 support

With one runtime going away, we now add support for the nodejs18.x runtime. In the past few weeks we have updated our CI workflows to continuously run unit and integration tests to include the new runtime. This has given us enough confidence to announce that the project is compatible with the runtime.

Bug fixes

Logger

This release adds support for BigInt to Logger. This type of objects cannot be natively serialized, so before to this release Logger would throw an error.

Now, if you try to log an object that contains a BigInt, Logger will automatically convert it to a string and log it for you:

import { Logger } from "@aws-lambda-powertools/logger";

const logger = new Logger();
logger.info('Object with bigint value', { myBigInt: BigInt(1234) })

will result in:

{
  "level": "INFO",
  "message": "Object with bigint value",
  "service": "service_undefined",
  "timestamp": "2022-10-12T22:27:17.067Z",
  "myBigInt": "1234"
}

Thanks @shdq for the fix!

Bundling with tsc

Prior to this release, customers using tsc to bundle their functions but not using any of the Powertools middleware, were experiencing build-time errors due to one of our dependencies not being tree-shaken correctly. This release introduces a change to the internals of our packages that allow those customers to use tsc without having to install an extra devDependency only to please the compiler.

Acknowledgments

A big thank you to @shdq for the continuous generous contributions 🙏, and a congrats to @niko-achilles for landing your first batch of PR merged 🎉

Finally, while still not published on npm, there's a lot of work being done on the upcoming Idempotency and Parameters utilities that the team and community are doing. You can follow the progress in the respective milestones here and here.

Changes

  • build(layers): aligned aws cdk versions in layer-publisher to main workspace (#1228) by @dreamorosi
  • build(deps): bump json5 from 1.0.1 to 1.0.2 (#1212) by @dependabot
  • build(deps): bump json5 from 1.0.1 to 1.0.2 in /layer-publisher (#1209) by @dependabot
  • build(deps): bump json5 from 1.0.1 to 1.0.2 in /examples/sam (#1210) by @dependabot
  • build(deps): bump json5 from 1.0.1 to 1.0.2 in /examples/cdk (#1211) by @dependabot
  • build(deps): bump decode-uri-component from 0.2.0 to 0.2.2 (#1185) by @dependabot

🌟New features and non-breaking changes

📜 Documentation updates

🐛 Bug and hot fixes

  • fix(logger): logger throws TypeError when log item has BigInt value (#1201) by @shdq

🔧 Maintenance

This release was made possible by the following contributors:

@bpauwels, @dreamorosi, @niko-achilles and @shdq

Contributors

shdq, dreamorosi, and 3 other contributors
Assets 2
Loading

v1.5.0

25 Nov 10:54
@github-actions github-actions
v1.5.0
3da04d7
Compare
Choose a tag to compare
v1.5.0

Summary

This release includes some bug fixes and quality of life improvements on the Logger utility as well as improvements on the bundle size of our public Lambda Layers.

Logger

Prior to this release, when creating child loggers, Logger was affected by a bug that caused some of the settings to not be properly reflected in its children. This release corrects the issue by reworking the logic used to create child loggers.

Additionally, thanks to @shdq's contribution, those who use jest and Logger can now leverage the --silent flag to silence logs emitted by Logger in their unit tests.

Lambda Layer

Thanks to a report from @Muthuveerappanv, we were able to shave ~3MB from the deployment package of our public Lambda Layers by removing @types from the node_modules folder. This will give you back some valuable space when using the layers.

Upcoming Utilities

The release also includes unreleased work on two new upcoming utilities: Idempotency and Parameters. On both fronts we have finished laying the foundations for the utilities and we will now start gradually adding features. Stay tuned for more updates on this topic in the next releases.

Governance

As part of this release we have also published a new and improved GitHub Project that you can use to stay updated with the team's progress as well as finding contributing opportunities. We also have added a new "Roadmap" section to the docs, use this page to learn about the team's priorities for the upcoming months.

Acknowledgements

A big thank you to @shdq who has been a big part of this release, to @ConnorKirk for his first contribution to the project, and to @jeffrey-baker-vg and the rest of the team for the hard work on Idempotency.

Changes

  • tests(idempotency): add utility to workspace unit tests and CI (#1160) by @dreamorosi
  • feat(idempotency): Add persistence layer and DynamoDB implementation (#1110) by @jeffrey-baker-vg
  • feat(logger): pretty printing logs in local and non-prod environment (#1141) by @shdq

🌟New features and non-breaking changes

🌟 Minor Changes

  • feat(logger): disable logs while testing with jest --silent in dev env (#1165) by @shdq

📜 Documentation updates

🐛 Bug and hot fixes

  • fix(logger): merge child logger options correctly (#1178) by @shdq

🔧 Maintenance

This release was made possible by the following contributors:

@ConnorKirk, @dreamorosi, @flochaz, @jeffrey-baker-vg and @shdq

Contributors

shdq, flochaz, and 5 other contributors
Assets 2
Loading

v1.4.1

09 Nov 14:30
@github-actions github-actions
v1.4.1
103a3a1
Compare
Choose a tag to compare
v1.4.1

Summary

This patch release fixes a bug in Metrics as well as introducing some improvements in the documentation and jsdoc examples that accompany all public APIs of the utilities.

The bug in Metrics caused the service name to be cleared from the default dimensions after metrics were published or after the first function invocation when using the middleware or decorator. The service name is automatically added to metrics emitted by the utility and should always be present as dimension.

Finally, thank you to @niko-achilles for helping raise the bar on the documentation. Below an example of the jsdoc string rendered in VS Code:
image

Changes

📜 Documentation updates

🐛 Bug and hot fixes

  • fix(metrics): store service name in defaultDimensions to avoid clearing it (#1146) by @dreamorosi

🔧 Maintenance

This release was made possible by the following contributors:

@dreamorosi and @github-actions[bot]

Contributors

dreamorosi and niko-achilles
Assets 2
Loading

v1.4.0

27 Oct 13:04
@github-actions github-actions
v1.4.0
e1cdc4c
Compare
Choose a tag to compare
v1.4.0

Summary

This release introduces a new feature in Tracer that allows customers to access the AWS X-Ray Root Trace ID. The release also includes a bug fix for Metrics where an issue prevented dimensions and metadata to be cleared on metrics publish. Finally, it also includes some updates to the docs, one of which introduces an example of how to use the Powertools layer with Pulumi.

Tracer

The Tracer utility now has a new public method called getRootXrayTraceId() (docs). With this method you can access the root trace id and use it in your responses or downstream processing as correlation id.

carbon-2

Thank you @misterjoshua for suggesting the feature and helping review the PR.

Metrics

Prior to this release a bug in the Metrics utility prevented metadata and dimensions of metrics to leak between function executions. This was due to a faulty logic that didn't clear properly the two objects when metrics were published. Thanks to @shdq the bug has been fixed and unit tests around the behavior were added. Congrats @shdq for your first PR merged 🎉

Docs

Finally, thanks to @pierskarsenbarg's first contribution to this repo (💯) , the documentation now has an example of how to use the Powertools layer with Pulumi!

carbon

Changes

🌟New features and non-breaking changes

  • feat(all): moved EnvService to commons + exposed getXrayTraceId in tracer (#1123) by @dreamorosi

📜 Documentation updates

🐛 Bug and hot fixes

  • fix(metrics): metadata and dimensions not cleared on publish (#1129) by @shdq

🔧 Maintenance

This release was made possible by the following contributors:

@dreamorosi, @pierskarsenbarg and @shdq

Contributors

pierskarsenbarg, misterjoshua, and 2 other contributors
Assets 2
Loading