feat(idempotency): add package exports

[dreamorosi]

Description of your changes

This PR sets the exports for the upcoming Idempotency module so that customers can import its modules easily while using the utility.

The exports the following structure:

import { makeFunctionIdempotent } from "@aws-lambda-powertools/idempotency";
import { IdempotencyRecord } from "@aws-lambda-powertools/idempotency/persistence";
import { DynamoDBPersistenceLayer } from "@aws-lambda-powertools/idempotency/dynamodb";

This structure allows to:

• have all the main modules (i.e. makeFunctionIdempotent, idempotencyConfig, etc.) at the top level
• have general persistence-related modules under /persistence
• and have a scoped import for the DynamoDBPersistenceLayer, which in the future will allow customers to tree-shake and avoid a dependency on @aws-sdk/lib-dynamodb if they decide to use a different persistence layer

In upcoming PRs, we'll also add an export for types (i.e. @aws-lambda-powertools/idempotency/types) and one for the Middy middleware (@aws-lambda-powertools/idempotency/middleware).

Implementation Details

These exports were possible thanks to the addition of a few new fields in the package.json of the utility, which allow us to specify the exports and control the paths in a way similar to aliases:

{
  "name": "@aws-lambda-powertools/idempotency",
  "exports": {
    ".": {
      "import": "./lib/index.js",
      "require": "./lib/index.js"
    },
    "./persistence": {
      "import": "./lib/persistence/index.js",
      "require": "./lib/persistence/index.js"
    },
    "./dynamodb": {
      "import": "./lib/persistence/DynamoDbPersistenceLayer.js",
      "require": "./lib/persistence/DynamoDbPersistenceLayer.js"
    }
  },
  "typesVersions": {
    "*": {
      "persistence": [
        "lib/persistence/index.d.ts"
      ],
      "dynamodb": [
        "lib/persistence/DynamoDbPersistenceLayer.d.ts"
      ]
    }
  },
  "main": "./lib/index.js",
  "types": "./lib/index.d.ts"
}

The benefits of this structure are several:

• we can have more freedom to reorganize the folder/project structure without causing breaking changes in the output
• we have more control over what's exposed and what isn't
• we can specify different destinations for different types of imports (i.e. import vs require)
• we can flatten and/or shorten the imports (i.e. @aws-lambda-powertools/idempotency/dynamodb vs @aws-lambda-powertools/idempotency/lib/persistence/DynamoDBPersistenceLayer)

This structure/pattern was heavily influenced by the work done by @shdq (thanks!) here and will be rolled out to all other modules in due process.

Related issues, RFCs

Issue number: #1479

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective and works
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.