@aws-sdk/core

@aws-sdk/core

This package provides common or core functionality to the AWS SDK for JavaScript (v3).

You do not need to explicitly install this package, since it will be transitively installed by AWS SDK clients.

@aws-sdk/core submodules

Core submodules are organized for distribution via the package.json exports field.

exports is supported by default by the latest Node.js, webpack, and esbuild. For react-native, it can be enabled via instructions found at reactnative.dev/blog.

Think of @aws-sdk/core as a mono-package within the monorepo. It preserves the benefits of modularization, for example to optimize Node.js initialization speed, while making it easier to have a consistent version of core dependencies, reducing package sprawl when installing an SDK client.

Guide for submodules

• Each index.ts file corresponding to the pattern ./src/submodules/<MODULE_NAME>/index.ts will be published as a separate dist-cjs bundled submodule index using the Inliner.js build script.
• create a folder as ./src/submodules/<SUBMODULE> including an index.ts file and a README.md file.
  • The linter will throw an error on missing submodule metadata in package.json and the various tsconfig.json files, but it will automatically fix them if possible.
• a submodule is equivalent to a standalone @aws-sdk/<pkg> package in that importing it in Node.js will resolve a separate bundle.
• submodules may not relatively import files from other submodules. Instead, directly use the @scope/pkg/submodule name as the import.
  • The linter will check for this and throw an error.
• To the extent possible, correctly declaring submodule metadata is validated by the linter in @aws-sdk/core. The linter runs during yarn build and also as yarn lint.

When should I create an @aws-sdk/core/submodule vs. @aws-sdk/new-package?

Keep in mind that the core package is installed by all AWS SDK clients.

If the component functionality is upstream of multiple clients, it is a good candidate for a core submodule. For example, XML serialization.

If the component's functionality is downstream of a client, for example S3 pre-signing, it should be a standalone package with potentially a peer or runtime dependency on an AWS SDK client.

Changelog

3.812.0 (2025-05-16)

Bug Fixes

• core/protocols: read error code case-insensitively (#7085) (c13a2a0)

Features

• client-bedrock-data-automation-runtime: Add AssetProcessingConfiguration for video segment to InputConfiguration (bbf9999)
• client-bedrock-data-automation: Add support for VIDEO modality to BlueprintType enum. (5657cb1)
• client-codepipeline: CodePipeline now supports new API ListDeployActionExecutionTargets that lists the deployment target details for deploy action executions. (eb51d8f)
• client-emr: Added APIs for managing Application UIs: Access Persistent (serverless) UIs via CreatePersistentAppUI DescribePersistentAppUI & GetPersistentAppUIPresignedURL, and Cluster-based UIs through GetOnClusterAppUIPresignedURL. Supports Yarn, Spark History, and TEZ interfaces. (f1f82e1)
• client-glue: Changes include (1) Excel as S3 Source type and XML and Tableau's Hyper as S3 Sink types, (2) targeted number of partitions parameter in S3 sinks and (3) new compression types in CSV/JSON and Parquet S3 sinks. (a5f2aef)
• client-neptune: This release adds Global Cluster Switchover capability which enables you to change your global cluster's primary AWS Region, the region that serves writes, while preserving the replication between all regions in the global cluster. (ab547b0)
• client-service-quotas: This release introduces CreateSupportCase operation to SDK. (611d06e)
• clients: update client endpoints as of 2025-05-16 (9a8d9b5)