Skip to content

Releases: aws-powertools/powertools-lambda-typescript

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
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
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
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
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
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
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
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
Loading

v1.3.0

17 Oct 16:00
@github-actions github-actions
v1.3.0
3a6d791
Compare
Choose a tag to compare
v1.3.0

Summary

This release adds public AWS Lambda Layers, a new feature for Tracer, and bug fixes on all utilities.

AWS Lambda Layers

You can now use AWS Lambda Powertools for TypeScript by adding just a few lines to your configs and using our public AWS Lambda Layers.

Lambda Layer is a .zip file archive that can contain additional code, pre-packaged dependencies, data, or configuration files. Layers promote code sharing and separation of responsibilities so that you can iterate faster on writing business logic.

You can include Lambda Powertools Lambda Layer using AWS Lambda Console, or your preferred deployment framework. Lambda Layers also allow us to understand who uses this library in a non-intrusive way. This helps us justify and gain future investments for other Lambda Powertools languages.

When using AWS SAM or Serverless Framework:

carbon-6

With CDK:

carbon-7

New Features

Tracer

When using the captureMethod decorator on your class method you can now specify a custom name for the subsegment that Tracer generates for you.

You can do so by passing a newly added subSegmentName parameter to the decorator. This is useful for those cases in which the decorated method has an long or non-meaningful name but also in cases in which you want to nest method calls and represent this nesting in the segment names by using different levels of ###/####.

carbon-5

Bug Fixes

Metrics

The Metrics utility has two parameters captureColdStartMetric and throwOnEmptyMetrics that allow respectively to create a cold start metric for those invocations that had an initialization phase, and to throw an error before flushing metrics to ensure that at least one metric is emitted.

Prior to this release there was a bug that caused the parameters to be misinterpreted when passed to the logMetrics middleware. This release ensures that the parameters are parsed correctly and adds additional tests to verify and maintain the behavior.

Logger

The indectLambdaContext decorator allows you to enrich your structured logs with key Lambda context information. The appendKeys method instead allows you to append additional keys and values to logs while within the function handler's scope.

Prior to this release there was a bug that caused some of these additional keys and values to be cleared too soon due to the decorator not awaiting for the decorated method to return. This release fixes the issue and adds tests to prevent future regressions.

Tracer

The captureMethod decorator allows you to trace Class methods and create segments for its operations.

Prior to this release, when using captureMethod with certain 3rd party decorators the name of the decorated method was not detected correctly causing the segment name and its annotation to be mislabeled. This release changes the logic around name detection to ensure names are properly annotated.

Changes

  • Chore(tracer): unit tests to verify decorators await decorated class methods (#1108) by @dreamorosi
  • Fix: standardized and consistent linting strategy across Lerna targets (#1105) by @saragerion

🌟New features and non-breaking changes

📜 Documentation updates

  • docs: update layer version in docs (#1120) by @dreamorosi
  • doc(layer): bump layer version to 2 to match the one built for latest version (1.2.1) (#1113) by @flochaz

🐛 Bug and hot fixes

  • fix(all): update version command to use lint-fix (#1119) by @dreamorosi
  • fix(tracer): captureMethod detects proper method name when used with external decorators (#1109) by @dreamorosi
  • fix(metrics): captureColdStartMetric and throwOnEmptyMetrics when set to false was interpreted as true (#1090) by @flochaz
  • fix(logger): wait for decorated method return before clearing out state (#1087) by @dreamorosi
  • fix(build): remove leftover code in action that labels issues on merge (#1078) by @dreamorosi

🔧 Maintenance

  • fix(all): update version command to use lint-fix (#1119) by @dreamorosi
  • chore(layer): fix bundling and e2e tests by manually setting hash of asset (#1116) by @flochaz
  • chore(build): fix ts-node version for layer-publisher (#1112) by @flochaz
  • build(deps): bump vm2 from 3.9.9 to 3.9.11 (#1094) by @dependabot
  • improv(build): allow to specify PR number when running e2e tests (#1079) by @dreamorosi
  • fix(build): remove leftover code in action that labels issues on merge (#1078) by @dreamorosi
  • chore(build): update make-release.yml to remove redundant publish step (#1075) by @dreamorosi

This release was made possible by the following contributors:

@dreamorosi, @flochaz, @jeffrey-baker-vg and @saragerion

Contributors

flochaz, dreamorosi, and 3 other contributors
Loading

v1.2.1

25 Aug 08:06
@github-actions github-actions
v1.2.1
34d3a76
Compare
Choose a tag to compare
v1.2.1

Summary

We are thrilled to share that we have a new home on Discord!
We hope that this new chapter will allow us to connect and learn from each other, as well as shape together the feature of Powertools.

Join us here: https://discord.gg/B8zZKbbyET

Thanks @sthuber90 for opening the PR to update our docs and adding the new link.

Changes

📜 Documentation updates

This release was made possible by the following contributors:

@sthuber90

Contributors

sthuber90
Loading