aws / aws-sdk-js-v3

Modularized AWS SDK for JavaScript.
Apache License 2.0
3.04k stars 569 forks source link

Support subpath exports for typescript #4461

Open brandonryan opened 1 year ago

brandonryan commented 1 year ago

Describe the feature

Right now if you try to import say, all the commands for a client, you get a typescript error.

import * as s3Commands from "@aws-sdk/client-s3/dist-es/commands/index.js"
Could not find a declaration file for module '@aws-sdk/client-sqs/dist-es/commands/index.js'. '[path-to-project]/node_modules/.pnpm/@aws-sdk+client-sqs@3.272.0/node_modules/@aws-sdk/client-sqs/dist-es/commands/index.js' implicitly has an 'any' type.
  If the '@aws-sdk/client-sqs' package actually exposes this module, try adding a new declaration (.d.ts) file containing `declare module '@aws-sdk/client-sqs/dist-es/commands/index.js';`

The module should instead provide exports path patterns to allow you to import any of the files in the module.

Use Case

I need to import all the commands in the module into an object, so I can look them up and do string manipulation on the keys. I am writing a web service that acts as an aws-sdk proxy because the module wont work in our legacy system.

Proposed Solution

I propose that the modules export using the nodejs "exports" feature in package.json

"exports": {
  "./*.js": {
    "import": "./dist-es/*.js",
    "require": "./dist-cjs/*.js",
    "types": "./dist-types/*.d.ts"
  },
  ".": {
    "import": "./dist-es/index.js",
    "require": "./dist-cjs/index.js",
    "types": "./dist-types/index.d.ts"
  }
},

Removed the main, types, and module fields.

This has some added benefit, removing the requirement to import the dist folder and instead letting node resolve the import path. For example, instead of "@aws-sdk/client-sqs/dist-es/commands/index.js you can just write "@aws-sdk/client-sqs/commands/index.js.

Other Information

You might have to add .mjs to all the import paths for module import, depending on the "mode" field in package.json. I'm not sure if nodejs is smart enough at runtime to resolve the module type when resolving the import paths without this. Had issues with it before.

Acknowledgements

SDK version used

3.272.0

Environment details (OS name and version, etc.)

Mac

github-actions[bot] commented 6 months ago

Greetings! We’re closing this issue because it has been open a long time and hasn’t been updated in a while and may not be getting the attention it deserves. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to comment or open a new issue.

brandonryan commented 6 months ago

Still wanted.

kuhe commented 5 months ago

Our current dist-cjs artifacts for Node.js runtimes export only 1 primary file per service, there is no way to separately retrieve a subset of commands for the CJS artifact used in Node.js.

For dist-es, which we do not currently offer for Node.js due to not having mjs file endings, we may consider subpath exports after May 2024 end of support for Node.js 14 due to a TypeScript compatibility issue.