@ddd-ts-kit/s3 0.16.0 → 0.16.1

package/README.fr.md

@@ -0,0 +1,211 @@
+[English](README.md) · **Français**
+<!-- translation-of: README.md sha256:1ff5474228b48807 -->
+
+# @ddd-ts-kit/s3
+
+Le `FileStorage` du noyau sur tout fournisseur du protocole S3 : AWS S3, MinIO, OVHcloud Object
+Storage, Scaleway, Cloudflare R2, Garage. Le contenu d'un fichier part en flux vers le bucket par
+parties, jamais entier en mémoire et jamais dans la base de données ; l'agrégat garde le
+`StoredFile` que renvoie `put`. Rien dans `domain/` ou `application/` n'importe ce *package* : les
+gestionnaires (handlers) dépendent du port `FileStorage`, et la plateforme lie cet adaptateur.
+
+```
+npm i @ddd-ts-kit/s3 @aws-sdk/client-s3 @aws-sdk/lib-storage @aws-sdk/s3-request-presigner
+```
+
+Les trois *packages* du SDK AWS v3 officiel sont des dépendances *peer* optionnelles, écrites pour
+la version 3.1150.
+
+![Les cas d'usage et FileStaging dépendent du port FileStorage du noyau ; S3FileStorage l'implémente, place chaque clé sous son préfixe et envoie ses commandes par un S3Client construit par s3ClientOf ; le client envoie et télécharge directement vers le bucket par des liens signés ; le bucket garde les fichiers promus sous leurs clés et les fichiers mis en attente sous staging/](https://raw.githubusercontent.com/gbourgeat/ddd-ts-kit/main/docs/assets/diagrams/s3-place-in-an-application.fr.svg)
+
+Les cas d'usage parlent au port avec des clés comme `appointment-documents/2026/10/7f3c`,
+générées par `TenantFileKeys`, le `FileKeys` du noyau : la zone, l'année, le mois, puis un
+identifiant issu de l'`IdGenerator` (précédés de `tenants/<tenant>/` quand le travail en cours
+désigne un tenant). L'adaptateur place son préfixe devant chaque clé
+(`scheduling/appointment-documents/2026/10/7f3c` dans le bucket), et `FileStaging` place
+`staging/` devant la clé d'un fichier qui attend sa validation
+(`scheduling/staging/appointment-documents/2026/10/9a1b`). Les octets d'un fichier vont du client
+au bucket, ou de l'API au bucket par parties, et la base de données ne garde que la référence.
+
+## Racine de composition
+
+<!-- checked sample -->
+```ts
+import type { FileStorage } from '@ddd-ts-kit/kernel';
+import { S3FileStorage, s3ClientOf } from '@ddd-ts-kit/s3';
+
+declare const config: {
+  readonly storage: {
+    readonly endpoint?: string;
+    readonly region: string;
+    readonly accessKeyId: string;
+    readonly secretAccessKey: string;
+    readonly bucket: string;
+  };
+};
+
+const { endpoint, region, accessKeyId, secretAccessKey, bucket } = config.storage;
+
+export const files: FileStorage = new S3FileStorage({
+  client: s3ClientOf({
+    ...(endpoint === undefined ? {} : { endpoint }), // omis pour AWS ; http://localhost:9000 pour MinIO
+    region, // 'auto' pour R2
+    accessKeyId,
+    secretAccessKey,
+  }),
+  bucket, // créé par le code d'infrastructure, jamais par l'application
+  prefix: 'scheduling/', // facultatif : plusieurs applications dans un seul bucket
+});
+```
+
+`s3ClientOf` active l'adressage par chemin (path-style) quand un endpoint est donné (MinIO et la
+plupart des serveurs auto-hébergés en ont besoin) et ne calcule d'empreinte (checksum) que
+lorsqu'une opération en exige une : par défaut, le SDK envoie une empreinte avec chaque requête,
+ce que refusent plusieurs fournisseurs qui ne sont pas AWS, et ce qui lierait un lien d'envoi
+signé à un corps vide. Un client construit à la main fonctionne aussi.
+
+Les options de `S3FileStorage` :
+
+| Option | Par défaut | |
+|---|---|---|
+| `client` | requis | un `S3Client`, issu de `s3ClientOf` ou construit à la main |
+| `bucket` | requis | il doit exister : l'adaptateur n'en crée jamais |
+| `prefix` | aucun | une clé valide terminée par `/`, placée devant chaque clé ; le constructeur en refuse toute autre |
+| `partSize` | 8 Mio | la taille de chaque partie d'un envoi, au moins 5 Mio : le maximum gardé en mémoire par envoi |
+| `clock` | l'horloge du système | donne l'heure des `expiresAt` que renvoient les liens signés |
+
+Un gestionnaire dépend du port, jamais du SDK :
+
+```ts
+// À éviter : le gestionnaire parle S3, garde tout le fichier en mémoire et nomme le bucket
+const body = Buffer.concat(await Array.fromAsync(rows));
+await s3.send(new PutObjectCommand({ Bucket: 'acme-files', Key: `exports/${id}.csv`, Body: body }));
+```
+
+<!-- checked sample -->
+```ts
+import { FileKeys, FileStorage, type StoredFile } from '@ddd-ts-kit/kernel';
+
+// Écrire : le port du noyau ; la plateforme y lie S3FileStorage, un test InMemoryFileStorage.
+export class ExportAppointments {
+  constructor(
+    private readonly files: FileStorage,
+    private readonly keys: FileKeys,
+  ) {}
+
+  async execute(csv: AsyncIterable<Uint8Array>): Promise<{ readonly file: StoredFile; readonly link: string }> {
+    const key = this.keys.next('appointment-exports');
+
+    // Part en flux vers le bucket par parties ; au-delà de 50 Mio, FILE_TOO_LARGE, et rien ne reste sous la clé.
+    const file = await this.files.put(key, csv, { mediaType: 'text/csv', maxBytes: 50 * 1_048_576 });
+
+    // Un GetObject présigné, calculé localement : aucune requête n'atteint le bucket.
+    const { url } = await this.files.signedDownloadUrl(key, { expiresInSeconds: 300, fileName: 'appointments.csv' });
+
+    return { file, link: url };
+  }
+}
+```
+
+## Ce qu'il fait
+
+| Méthode du port | Sur le bucket |
+|---|---|
+| `put(key, stream, { mediaType, maxBytes })` | un envoi *multipart* en parties de `partSize` (8 Mio par défaut, une seule en mémoire à la fois), ou un seul `PutObject` quand le contenu tient dans une partie ; le contenu est compté et haché au passage, et refusé avec `FILE_TOO_LARGE` au-delà de `maxBytes`, ce qui abandonne l'envoi et laisse l'objet précédent |
+| `get`, `stat` | `GetObject` en flux, `HeadObject` ; `undefined` quand l'objet n'existe pas, un rejet quand le service est injoignable |
+| `delete` | `DeleteObject`, idempotent |
+| `copy`, `move` | `CopyObject`, fait par le service (et `DeleteObject` pour un déplacement), jusqu'à 5 Gio par objet |
+| `list(prefix)` | `ListObjectsV2`, page après page |
+| `signedDownloadUrl` | un `GetObject` présigné, servi avec `Content-Disposition: attachment`, avec le nom du fichier quand il est donné |
+| `signedUploadUrl` | un `PutObject` présigné dont la signature couvre le `content-type` : un autre type de média est refusé par le service |
+
+L'empreinte (`sha256:<hex>`) est renvoyée par `put`, calculée pendant que le contenu passe ; le
+bucket ne la garde pas, si bien que `stat` n'en renvoie aucune. Un fichier envoyé par un lien signé
+est mesuré, vérifié et haché par `FileStaging.confirm` du noyau, qui le relit.
+
+Une clé que le port refuse (`../escape`) est refusée avec `INVALID_FILE_KEY`, et un lien demandé
+pour plus d'une heure avec `INVALID_FILE_URL_EXPIRY`, avant toute requête. La signature ne
+demande pas de requête non plus : un lien signé est calculé à partir des identifiants d'accès, et
+seul le fournisseur le vérifie, quand le client l'utilise.
+
+![Un envoi par lien signé : le client demande un lien, FileStaging.uploadUrl fait signer un PUT localement par S3FileStorage et garde l'autorisation d'envoi sur l'agrégat, le client envoie le fichier directement au bucket, qui vérifie la clé, la méthode, le content-type et l'expiration mais ne peut pas plafonner la taille ; puis le client confirme, et FileStaging.confirm relit l'objet mis en attente pour vérifier sa taille contre le plafond, son type de média, son empreinte et l'analyse](https://raw.githubusercontent.com/gbourgeat/ddd-ts-kit/main/docs/assets/diagrams/s3-signed-upload.fr.svg)
+
+Le client envoie le fichier exactement comme le dit le lien, avec les en-têtes qu'il a reçus :
+
+<!-- checked sample -->
+```ts
+import type { SignedUpload } from '@ddd-ts-kit/kernel';
+
+// Dans le client : la signature couvre le content-type, les en-têtes sont donc envoyés tels quels.
+export async function sendFile(link: SignedUpload, file: Blob): Promise<void> {
+  const response = await fetch(link.url, { method: link.method, headers: link.headers, body: file });
+
+  if (!response.ok) {
+    throw new Error(`The storage refused the upload: ${response.status}`); // 403 une fois expiré, ou pour un autre type
+  }
+}
+```
+
+## Limites
+
+- Un lien d'envoi signé ne peut pas plafonner la taille de ce qui est envoyé (seule une politique
+  de POST présigné le peut) : son `maxBytes` n'est pas appliqué par le service, et
+  `FileStaging.confirm` mesure le fichier contre le plafond de l'autorisation d'envoi que le
+  serveur a gardée, et le supprime au-delà.
+- La copie et le déplacement passent par `CopyObject`, limité à 5 Gio par objet par le protocole.
+- Un envoi compte au plus 10 000 parties : avec des parties de 8 Mio, un fichier d'environ 78 Gio.
+  Augmentez `partSize` pour des fichiers plus gros.
+- Les règles de cycle de vie, le versionnement, le verrouillage d'objet (object lock) et le
+  chiffrement du bucket sont des réglages du bucket, faits par le code d'infrastructure du
+  déploiement, pas par cet adaptateur.
+
+## Tests
+
+Le contrat du port est tenu contre un vrai serveur : `fileStorageContract` de
+`@ddd-ts-kit/testing/contracts` (réexporté par `@ddd-ts-kit/s3/testing`) s'exécute sur MinIO dans
+le *job* d'intégration du *pipeline*, avec la variable `DDD_TS_KIT_TEST_S3_ENDPOINT` définie ;
+sans elle, les *specs* qui ont besoin d'un serveur sont ignorées. Le projet MinIO amont a cessé
+de publier des images en 2025 : le *pipeline* exécute `pgsty/minio`, construit à partir des
+mêmes sources, épinglé par *digest* (`pipeline/github/scripts/start-minio.sh`).
+
+```
+docker run -d --name minio -p 127.0.0.1:9000:9000 -e MINIO_ROOT_USER=ddd-ts-kit -e MINIO_ROOT_PASSWORD=ddd-ts-kit-secret pgsty/minio:RELEASE.2026-08-04T00-00-00Z server /data
+DDD_TS_KIT_TEST_S3_ENDPOINT=http://localhost:9000 npx vitest run packages/s3
+```
+
+Un projet tient sa propre liaison à la même suite, sur le MinIO de sa *stack* compose : chaque
+test écrit sous un préfixe à lui, si bien que les tests partagent un seul bucket sans voir les
+fichiers des autres.
+
+<!-- checked sample -->
+```ts
+import { randomBytes } from 'node:crypto';
+import { beforeEach, describe, expect, it } from 'vitest';
+import { S3FileStorage, s3ClientOf } from '@ddd-ts-kit/s3';
+import { fileStorageContract } from '@ddd-ts-kit/s3/testing';
+
+const endpoint = process.env['S3_TEST_ENDPOINT'] ?? '';
+
+// Ignoré sans serveur ; le bucket est créé au préalable, comme dans un déploiement.
+fileStorageContract(
+  { describe: describe.runIf(endpoint !== ''), it, expect, beforeEach },
+  {
+    name: 'S3FileStorage on MinIO',
+    createStorage: () =>
+      new S3FileStorage({
+        client: s3ClientOf({ endpoint, region: 'us-east-1', accessKeyId: 'minio', secretAccessKey: 'minio-secret' }),
+        bucket: 'acme-files-test',
+        prefix: `run-${randomBytes(6).toString('hex')}/`,
+      }),
+    // Les liens d'un vrai serveur expirent en temps réel.
+    elapse: (ms) => new Promise((resolve) => setTimeout(resolve, ms)),
+  },
+);
+```
+
+## Un autre fournisseur
+
+Google Cloud Storage et Azure Blob Storage parlent leurs propres protocoles. Un connecteur pour
+l'un d'eux est une classe qui étend `FileStorage` du noyau et passe `fileStorageContract` contre
+le vrai service ou son émulateur (fake-gcs-server, Azurite) : voir
+[Connecteurs de stockage de fichiers](../../docs/tools/file-storage.fr.md).

package/README.md

@@ -1,9 +1,11 @@
+**English** · [Français](README.fr.md)
+
 # @ddd-ts-kit/s3
 
 The kernel `FileStorage` on any provider of the S3 protocol: AWS S3, MinIO, OVHcloud Object
 Storage, Scaleway, Cloudflare R2, Garage. The content of a file streams to the bucket in parts,
 never whole in memory and never in the database; the aggregate keeps the `StoredFile` that `put`
-answers. Nothing in `domain/` or `application/` imports this package: handlers depend on the
+returns. Nothing in `domain/` or `application/` imports this package: handlers depend on the
 `FileStorage` port, and the platform binds this adapter.
 
 ```
@@ -12,19 +14,44 @@ npm i @ddd-ts-kit/s3 @aws-sdk/client-s3 @aws-sdk/lib-storage @aws-sdk/s3-request
 
 The three packages of the official AWS SDK v3 are optional peers, written against 3.1150.
 
+![The use cases and FileStaging depend on the FileStorage port of the kernel; S3FileStorage implements it, maps each key under its prefix and sends its commands through an S3Client built by s3ClientOf; the client uploads and downloads straight to the bucket with signed links; the bucket holds promoted files under their keys and staged files under staging/](https://raw.githubusercontent.com/gbourgeat/ddd-ts-kit/main/docs/assets/diagrams/s3-place-in-an-application.svg)
+
+The use cases speak to the port with keys such as `appointment-documents/2026/10/7f3c`,
+generated by `TenantFileKeys`, the `FileKeys` of the kernel: the area, the year, the month, then
+an id from the `IdGenerator` (and `tenants/<tenant>/` before them when the work names a tenant).
+The adapter puts its prefix before every key (`scheduling/appointment-documents/2026/10/7f3c` in
+the bucket), and `FileStaging` puts `staging/` before the key of a file that waits for its commit
+(`scheduling/staging/appointment-documents/2026/10/9a1b`). The bytes of a file go from the
+client to the bucket, or from the API to the bucket in parts, and the database keeps only the
+reference.
+
 ## Composition root
 
+<!-- checked sample -->
 ```ts
+import type { FileStorage } from '@ddd-ts-kit/kernel';
 import { S3FileStorage, s3ClientOf } from '@ddd-ts-kit/s3';
 
-const files = new S3FileStorage({
+declare const config: {
+  readonly storage: {
+    readonly endpoint?: string;
+    readonly region: string;
+    readonly accessKeyId: string;
+    readonly secretAccessKey: string;
+    readonly bucket: string;
+  };
+};
+
+const { endpoint, region, accessKeyId, secretAccessKey, bucket } = config.storage;
+
+export const files: FileStorage = new S3FileStorage({
   client: s3ClientOf({
-    endpoint: config.storage.endpoint, // left out for AWS; http://localhost:9000 for MinIO
-    region: config.storage.region, // 'auto' for R2
-    accessKeyId: config.storage.accessKeyId,
-    secretAccessKey: config.storage.secretAccessKey,
+    ...(endpoint === undefined ? {} : { endpoint }), // left out for AWS; http://localhost:9000 for MinIO
+    region, // 'auto' for R2
+    accessKeyId,
+    secretAccessKey,
   }),
-  bucket: config.storage.bucket, // created by the infrastructure code, never by the application
+  bucket, // created by the infrastructure code, never by the application
   prefix: 'scheduling/', // optional: several applications in one bucket
 });
 ```
@@ -34,11 +61,54 @@ servers need it) and computes checksums only when an operation requires one: the
 SDK sends a checksum with every request, which several providers that are not AWS refuse, and
 which would bind a signed upload link to an empty body. A client built by hand works too.
 
+The options of `S3FileStorage`:
+
+| Option | Default | |
+|---|---|---|
+| `client` | required | an `S3Client`, from `s3ClientOf` or built by hand |
+| `bucket` | required | it must exist: the adapter never creates one |
+| `prefix` | none | a valid key ending with `/`, put before every key; the constructor refuses another |
+| `partSize` | 8 MiB | the size of each part of an upload, at least 5 MiB: the most held in memory per upload |
+| `clock` | the system clock | gives the `expiresAt` the signed links return |
+
+A handler depends on the port, never on the SDK:
+
+```ts
+// Instead of: the handler speaks S3, holds the whole file in memory, and names the bucket
+const body = Buffer.concat(await Array.fromAsync(rows));
+await s3.send(new PutObjectCommand({ Bucket: 'acme-files', Key: `exports/${id}.csv`, Body: body }));
+```
+
+<!-- checked sample -->
+```ts
+import { FileKeys, FileStorage, type StoredFile } from '@ddd-ts-kit/kernel';
+
+// Write: the port of the kernel; the platform binds S3FileStorage to it, a test InMemoryFileStorage.
+export class ExportAppointments {
+  constructor(
+    private readonly files: FileStorage,
+    private readonly keys: FileKeys,
+  ) {}
+
+  async execute(csv: AsyncIterable<Uint8Array>): Promise<{ readonly file: StoredFile; readonly link: string }> {
+    const key = this.keys.next('appointment-exports');
+
+    // Streams to the bucket in parts; beyond 50 MiB, FILE_TOO_LARGE, and nothing is left under the key.
+    const file = await this.files.put(key, csv, { mediaType: 'text/csv', maxBytes: 50 * 1_048_576 });
+
+    // A presigned GetObject, computed locally: no request reaches the bucket.
+    const { url } = await this.files.signedDownloadUrl(key, { expiresInSeconds: 300, fileName: 'appointments.csv' });
+
+    return { file, link: url };
+  }
+}
+```
+
 ## What it does
 
 | Port method | On the bucket |
 |---|---|
-| `put(key, stream, { mediaType, maxBytes })` | a multipart upload of `partSize` parts (8 MiB by default, one in memory at a time); the content is counted and hashed on its way, and refused with `FILE_TOO_LARGE` beyond `maxBytes`, which aborts the upload and leaves the previous object |
+| `put(key, stream, { mediaType, maxBytes })` | a multipart upload of `partSize` parts (8 MiB by default, one in memory at a time), or a single `PutObject` when the content fits in one part; the content is counted and hashed on its way, and refused with `FILE_TOO_LARGE` beyond `maxBytes`, which aborts the upload and leaves the previous object |
 | `get`, `stat` | `GetObject` as a stream, `HeadObject`; `undefined` when the object does not exist, a rejection when the service cannot be reached |
 | `delete` | `DeleteObject`, idempotent |
 | `copy`, `move` | `CopyObject` done by the service (and `DeleteObject` for a move), up to 5 GiB per object |
@@ -46,16 +116,41 @@ which would bind a signed upload link to an empty body. A client built by hand w
 | `signedDownloadUrl` | a presigned `GetObject` answered with `Content-Disposition: attachment`, with the file name when one is given |
 | `signedUploadUrl` | a presigned `PutObject` whose signature covers the `content-type`: another media type is refused by the service |
 
-The checksum (`sha256:<hex>`) is answered by `put`, computed while the content streams; the
-bucket does not keep it, so `stat` does not answer one. A file uploaded through a signed link
+The checksum (`sha256:<hex>`) is returned by `put`, computed while the content streams; the
+bucket does not keep it, so `stat` does not return one. A file uploaded through a signed link
 is measured, checked and hashed by `FileStaging.confirm` of the kernel, which reads it back.
 
+A key the port refuses (`../escape`) is refused with `INVALID_FILE_KEY`, and a link asked for
+more than an hour with `INVALID_FILE_URL_EXPIRY`, before any request. Signing needs no request
+either: a signed link is computed from the credentials, and only the provider checks it, when
+the client uses it.
+
+![An upload through a signed link: the client asks for a link, FileStaging.uploadUrl has S3FileStorage sign a PUT locally and keeps the grant on the aggregate, the client sends the file straight to the bucket, which checks the key, method, content-type and expiry but cannot cap the size; then the client confirms, and FileStaging.confirm reads the staged object back to check its size against the cap, its media type, its checksum and the scan](https://raw.githubusercontent.com/gbourgeat/ddd-ts-kit/main/docs/assets/diagrams/s3-signed-upload.svg)
+
+The client sends the file exactly as the link says, with the headers it was given:
+
+<!-- checked sample -->
+```ts
+import type { SignedUpload } from '@ddd-ts-kit/kernel';
+
+// In the client: the signature covers the content-type, so the headers are sent as they are.
+export async function sendFile(link: SignedUpload, file: Blob): Promise<void> {
+  const response = await fetch(link.url, { method: link.method, headers: link.headers, body: file });
+
+  if (!response.ok) {
+    throw new Error(`The storage refused the upload: ${response.status}`); // 403 once expired, or for another type
+  }
+}
+```
+
 ## Limits
 
 - A signed upload link cannot cap the size of what is sent (only a presigned POST policy can):
   its `maxBytes` is not enforced by the service, and `FileStaging.confirm` measures the file
   against the cap of the grant the server kept and discards it beyond.
 - Copy and move go through `CopyObject`, limited to 5 GiB per object by the protocol.
+- An upload has at most 10 000 parts: with parts of 8 MiB, a file of about 78 GiB. Raise
+  `partSize` for larger files.
 - Lifecycle rules, versioning, object lock and the encryption of the bucket are settings of the
   bucket, made by the infrastructure code of the deployment, not by this adapter.
 
@@ -73,6 +168,36 @@ docker run -d --name minio -p 127.0.0.1:9000:9000 -e MINIO_ROOT_USER=ddd-ts-kit
 DDD_TS_KIT_TEST_S3_ENDPOINT=http://localhost:9000 npx vitest run packages/s3
 ```
 
+A project holds its own binding to the same suite, on the MinIO of its compose stack: each test
+writes under a prefix of its own, so the tests share one bucket without seeing each other's
+files.
+
+<!-- checked sample -->
+```ts
+import { randomBytes } from 'node:crypto';
+import { beforeEach, describe, expect, it } from 'vitest';
+import { S3FileStorage, s3ClientOf } from '@ddd-ts-kit/s3';
+import { fileStorageContract } from '@ddd-ts-kit/s3/testing';
+
+const endpoint = process.env['S3_TEST_ENDPOINT'] ?? '';
+
+// Skipped without a server; the bucket is created beforehand, as in a deployment.
+fileStorageContract(
+  { describe: describe.runIf(endpoint !== ''), it, expect, beforeEach },
+  {
+    name: 'S3FileStorage on MinIO',
+    createStorage: () =>
+      new S3FileStorage({
+        client: s3ClientOf({ endpoint, region: 'us-east-1', accessKeyId: 'minio', secretAccessKey: 'minio-secret' }),
+        bucket: 'acme-files-test',
+        prefix: `run-${randomBytes(6).toString('hex')}/`,
+      }),
+    // The links of a real server expire in real time.
+    elapse: (ms) => new Promise((resolve) => setTimeout(resolve, ms)),
+  },
+);
+```
+
 ## Another provider
 
 Google Cloud Storage and Azure Blob Storage speak their own protocols. A connector for one of

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ddd-ts-kit/s3",
-  "version": "0.16.0",
+  "version": "0.16.1",
   "description": "Adapter of the kernel FileStorage port on the S3 protocol (AWS S3, MinIO, OVHcloud, Scaleway, Cloudflare R2): streamed uploads, signed links, copy, move, listing.",
   "license": "MIT",
   "repository": {
@@ -30,13 +30,13 @@
     "dist"
   ],
   "dependencies": {
-    "@ddd-ts-kit/kernel": "0.16.0"
+    "@ddd-ts-kit/kernel": "0.16.1"
   },
   "peerDependencies": {
     "@aws-sdk/client-s3": "^3.1150.0",
     "@aws-sdk/lib-storage": "^3.1150.0",
     "@aws-sdk/s3-request-presigner": "^3.1150.0",
-    "@ddd-ts-kit/testing": "0.16.0"
+    "@ddd-ts-kit/testing": "0.16.1"
   },
   "peerDependenciesMeta": {
     "@aws-sdk/client-s3": {
@@ -56,6 +56,6 @@
     "@aws-sdk/client-s3": "3.1150.0",
     "@aws-sdk/lib-storage": "3.1150.0",
     "@aws-sdk/s3-request-presigner": "3.1150.0",
-    "@ddd-ts-kit/testing": "0.16.0"
+    "@ddd-ts-kit/testing": "0.16.1"
   }
 }