aws-sdk-js-v3: Error Module has no exported member 'UserAgent' while using aws-sdk-js-v3

Describe the bug I am using aws-sdk-js-v3 in my typescript project, I installed package with command yarn add @aws-sdk/client-s3. After using S3Client in my typescript code

import { S3Client } from '@aws-sdk/client-s3';

Application starts failing with error

node_modules/@aws-sdk/client-s3/types/S3Client.d.ts:102:392 - error TS2305: Module '"../../types/dist/cjs"' has no exported member 'UserAgent'.
102 import { Provider, RegionInfoProvider, Credentials as __Credentials, Decoder as __Decoder, Encoder as __Encoder, EventStreamSerdeProvider as __EventStreamSerdeProvider, HashConstructor as __HashConstructor, HttpHandlerOptions as __HttpHandlerOptions, Logger as __Logger, Provider as __Provider, StreamCollector as __StreamCollector, StreamHasher as __StreamHasher, UrlParser as __UrlParser, UserAgent as __UserAgent } from "@aws-sdk/types";  
                                                                                   ~~~~~~~~~
node_modules/@aws-sdk/middleware-user-agent/dist/cjs/configurations.d.ts:1:20 - error TS2305: Module '"../../../types/dist/cjs"' has no exported member 'UserAgent'.

1 import { Provider, UserAgent } from "@aws-sdk/types";

SDK version number 3.1.0

Is the issue in the browser/Node.js/ReactNative? Node.js

Details of the Node.js version $ node -v v12.4.0

To Reproduce (observed behavior)

  1. Install package with command yarn add @aws-sdk/client-s3
  2. Import S3Client in typescript file import { S3Client } from ‘@aws-sdk/client-s3’; and use client to get object from S3.
  3. Start typescript application with command yarn run start:Dev
  4. It fails to start with given command

Note: If I install package @aws-sdk/types with command yarn add @aws-sdk/types then this error goes away and works as expected. Do we really need @aws-sdk/types package, Expectation was @aws-sdk/client-s3 will be sufficient.

Expected behavior It should not give any error and extra package @aws-sdk/types should not be needed

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 26
  • Comments: 30 (11 by maintainers)

Most upvoted comments

Hey everyone, I just wanted to let you know that the following seems to fix this issue:

  1. As @kirintwn mentioned, install the types package:
    npm install -D @aws-sdk/types@3.1.0
    
  2. Then upgrade Typescript, I’m on 4.1.3:
    npm install typescript@latest
    

I hope this is useful.

Installing @aws-sdk/types as above made this error go away, but then I got another error:

node_modules/@aws-sdk/types/dist/cjs/util.d.ts:92:42 - error TS1005: ',' expected.

92 export declare type UserAgentPair = [name: string, version?: string];
                                            ~
node_modules/@aws-sdk/types/dist/cjs/util.d.ts:92:60 - error TS1005: ',' expected.

92 export declare type UserAgentPair = [name: string, version?: string];

I guess that package doesn’t work with strict mode enabled.

I am also getting same issue.Looking for any solution.

I am running into this error as well. I’m using v3.1.0 of the SDK.

I see it with a few other clients as well

  • ../../node_modules/@aws-sdk/client-dynamodb/types/DynamoDBClient.d.ts:58:304 - error TS2305: Module '"../../types/dist/cjs"' has no exported member 'UserAgent'.
  • ../../node_modules/@aws-sdk/client-api-gateway/types/APIGatewayClient.d.ts:128:304 - error TS2305: Module '"../../types/dist/cjs"' has no exported member 'UserAgent'.
  • ../../node_modules/@aws-sdk/client-s3/types/S3Client.d.ts:102:392 - error TS2305: Module '"../../types/dist/cjs"' has no exported member 'UserAgent'.

What appears to be going is that all three of these clients have a dependencies on

  • @aws-sdk/types@3.1.0 and
  • @aws-crypto/sha256-browser@^1.0.0 - which in turn depends on @aws-sdk/types@^1.0.0-rc.1

I’m using yarn and when I grep through my node_modules, I don’t see @aws-sdk/types@3.1.0 only @aws-sdk/types@^1.0.0-rc.1. Hence when these clients are trying to import from @aws-sdk/types they’re getting v1.0.0-rc1 when they are expecting to get v3.1.0

It looks like this was probably introduced in https://github.com/aws/aws-sdk-js-v3/pull/1775

It looks like this would be fixed by https://github.com/aws/aws-sdk-js-crypto-helpers/pull/187

Adding this to my package.json is working as a temporary work-around for me (again, using yarn)

"resolutions": {
  "@aws-sdk/types": "^3.1.0"
}

Using the the above temporary work-around resolutions in package.json is not working for me (using npm).

I have to explicitly install @aws-sdk/types as one of devDependencies, then the problems are gone:

npm install -D @aws-sdk/types@3.1.0

As of yesterday’s v3.3.0 release, this issue appears to be fixed. No more need for the workarounds. Thanks for getting that release out last night AWS team.

Posting this here for documentation and visibility.

TLDR: We’re moving @aws-sdk/types to dependencies so that you get types right out of the box at the cost of an increase of 492kb in package size. This will not impact users that use bundlers.


After some investigation we’ve come to the conclusion that @aws-sdk/types should be exposed as a "dependency" in all packages where a non-test file depends on types. I’ll be making updates to @aws-crypto/* and @aws-sdk/* shortly. I’ve published my own versions to my local npm registry to confirm that these updates should fix this family of issues moving forward.

Background Customers consume @aws-sdk/* with types but we declare @aws-sdk/types as a devDependency in all packages in this repo. @trivikr showed in https://github.com/aws/aws-sdk-js-v3/issues/1842#issuecomment-755738925 that right now customers are getting access to @aws-sdk/types somewhat erroneously through a version of @aws-crypto/sha256-{js, browser} which brings in the most recent rc version of @aws-sdk/types as a dependency, since this is the only place where @aws-sdk/types are declared as a dependency, this is what consumers of @aws-sdk are actually using for @aws-sdk/types under the hood and why it hadn’t broken until types were updated with useragent in 3.1.0.

Like @olokobayusuf mentioned including @aws-sdk/types as a dependency yourself will also fix the issue.

Why are we doing this? When a package is declared as a devDependency it is (rightfully) not propagated to downstream consumers of that package. We publish packages that are consumed by downstream users, they should have access to types right out of the box without the need to install @aws-sdk/types themselves. Since we want our consumers to automatically get our type declarations we must declare these types as dependencies. See: https://github.com/Microsoft/types-publisher/issues/81#issuecomment-234051345

Wont this increase node module size? Yes, it will increase node module size by ~492kb. This is an issue brought up https://github.com/aws/aws-sdk-js-v3/issues/1649. However, @DanielRosenwasser brings up a good point in https://github.com/Microsoft/types-publisher/issues/81#issuecomment-234051345 that

breaking consumers is a worse problem than slightly-larger packages, we’ve made --save the default in our documentation.

The AWS SDK team (and I personally) agree. Additionally most JS users use bundlers anyway that should strip out these files.

Thanks everyone for the thorough investigation. @olokobayusuf 's solution should solve the problem. Although the @aws-sdk/client-s3@3.1.0 should have pinned dependency over @aws-sdk/types@3.1.0. We need to dive deeper into this on our end.

This should be going out with our next release. Huge shout out to @olokobayusuf!

Since a couple PR’s were merged in over in https://github.com/aws/aws-sdk-js-crypto-helpers, I think this is now just blocked on a new release of the various packages from that repo.

The next version of crypto-helpers is expected to release on Wed 1/13. We’ll release JS SDK v3 v3.3.0 consuming new crypto-helpers version by Thu 1/14

@MarrickLip We’re working on it, I dont have anything I can post to the public quite yet

Still seeing this bug with yesterday’s release of the SDK, v3.2.0, on both typescript 4.0 & 4.1.

Since a couple PR’s were merged in over in https://github.com/aws/aws-sdk-js-crypto-helpers, I think this is now just blocked on a new release of the various packages from that repo.

/cc @seebees

This issue is happening as @aws-sdk/types is declared as a dependency instead of devDependency in the following packages:

  • @aws-crypto/sha256-browser
  • @aws-crypto/sha256-js
  • @aws-sdk/util-user-agent-browser
  • @aws-sdk/util-user-agent-node
$ yarn why @aws-sdk/types
yarn why v1.22.10
warning package.json: No license field
[1/4] 🤔  Why do we have the module "@aws-sdk/types"...?
[2/4] 🚚  Initialising dependency graph...
warning No license field
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "@aws-sdk/types@1.0.0-rc.3"
info Has been hoisted to "@aws-sdk/types"
info Reasons this module exists
   - Hoisted from "@aws-sdk#client-s3#@aws-crypto#sha256-browser#@aws-sdk#types"
   - Hoisted from "@aws-sdk#client-s3#@aws-crypto#sha256-js#@aws-sdk#types"
info Disk size without dependencies: "524KB"
info Disk size with unique dependencies: "524KB"
info Disk size with transitive dependencies: "524KB"
info Number of shared dependencies: 0
=> Found "@aws-sdk/util-user-agent-browser#@aws-sdk/types@3.1.0"
info This module exists because "@aws-sdk#client-s3#@aws-sdk#util-user-agent-browser" depends on it.
info Disk size without dependencies: "540KB"
info Disk size with unique dependencies: "540KB"
info Disk size with transitive dependencies: "540KB"
info Number of shared dependencies: 0
=> Found "@aws-sdk/util-user-agent-node#@aws-sdk/types@3.1.0"
info This module exists because "@aws-sdk#client-s3#@aws-sdk#util-user-agent-node" depends on it.
info Disk size without dependencies: "540KB"
info Disk size with unique dependencies: "540KB"
info Disk size with transitive dependencies: "540KB"
info Number of shared dependencies: 0
✨  Done in 0.16s.

ToDo: Move @aws-sdk/types to devDependency in the affected packages.

@olokobayusuf thanks your solution worked for me.