Is there a version compatibility matrix for @aws-amplify?

0

@aws-amplify is a little bit of an opaque project. It's hard to open a non-bug issue, and the new issues template page for usage questions points to a discussions section that doesn't exist. I think they deleted the discussions, but I'm not sure.

I am working with @aws-amplify/storage version Amplify Storage makes this call:

the problem is:

TS2345: Argument of type 'PutObjectCommandInput' is not assignable to parameter of type 'PutObjectRequest'.
  Types of property 'Body' are incompatible.
    Type 'string | Blob | Readable | ReadableStream<any> | Uint8Array | Buffer' is not assignable to type 'Blob | Readable | ReadableStream<any>'.
      Type 'string' is not assignable to type 'Blob | Readable | ReadableStream<any>'.
    553 |
    554 |               const emitter = new events.EventEmitter();
  > 555 |               const uploader = new AWSS3ProviderManagedUpload(params, opt, emitter);
        |                                                               ^^^^^^
    556 |
    557 |               if (acl) {
    558 |                       params.ACL = acl;

const uploader = new AWSS3ProviderManagedUpload(params, opt, emitter);

The constructor it's calling is in AWSS3ProviderManagedUpload.ts and is typed as:

constructor(params: PutObjectRequest, opts, emitter: events.EventEmitter)

However, when they attempt to create that opts object it is done as:

const params: PutObjectCommandInput = {
	Bucket: bucket,
	Key: key,
	Body: object,
	ContentType: type,
};

The caller end is sending in a PutObjectCommandInput, but the constructor expects a PutObjectRequest. In terms of object hieararchy, a PutObjectCommandInput is a PutObjectCommandInputType which is in @aws-sdk/client-s3 as:

declare type PutObjectCommandInputType = Omit<PutObjectRequest, "Body"> & {
    /**
     * For *`PutObjectRequest["Body"]`*, see {@link PutObjectRequest.Body}.
     */
    Body?: PutObjectRequest["Body"] | string | Uint8Array | Buffer;
};

so there lies the problem: two different versions of Body. One shown above, the other is in @aws-amplify/storage as:

Body?: Readable | ReadableStream | Blob;

I think this is a version problem. Trying to trace this down, @aws-amplify/storage calls out: "@aws-sdk/client-s3": "3.6.1", which is fairly old. I'm using more modern everything:

    "@aws-amplify/core": "^5.0.8",
    "@aws-amplify/storage": "^5.0.8",
    "@aws-sdk/client-s3": "^3.238.0",

but to try to troubleshoot this I removed the direct dependency to client-s3 then cleaned node_modules. A reinstall caused yarn to pull version 3.6.1 back in, but the incompatibility still exists.

This seems like kind of a mess. Is there some kind of version/dependency map that would tell me how to resolve this? Is my only recourse to go back to aws-sdk /client-s3 3.6.1? That seems undesirable, doesn't it?

profile picture
wz2b
asked a year ago227 views
1 Answer
1

Hello,

I sincerely apologize for the inconvenience caused due to the behaviour observed at your end.

I see that you have opened the following Github issues with the Amplify development team related to the observed behaviour :-

[+] https://github.com/aws-amplify/amplify-js/issues/10828 [+] https://github.com/aws-amplify/amplify-js/issues/10824

As the GitHub issue has been assigned to an engineer and this issue is actively being worked upon, I would request you to kindly lookout for further updates on the above GitHub issue itself. Rest assured, I have reached out to the team internally and requested them to provide an update on the above issues.

I would greatly appreciate your understanding here.

Thank you

AWS
SUPPORT ENGINEER
answered a year ago
  • Kandadai thank you very much for your note! I did open a couple of related issues, after having already posted this on repost. I realized after I posted here that this would be more complicated to fix. I still want everybody to be aware that at this moment @aws-amplify is built on typescript 3.x.x and it is going to require a bigger effort to make it work with 4.x.x however @aws-amplify/auth works with 4.9.4 out of the box. The storage module has issues, but I forked/built the code and if the dev team wishes I'll try to fix it and offer some pull requests. Thanks for your response!

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions