CommonJS dist is imported instead of ESModule when using Node.js with ESModules, causing import errors.

[dsommerich]

Describe the bug

When importing the SDK from a plain ESModule file in Node.js (i.e. without using a bundler), Node.js attempts to import the CommonJS dist (@aws-sdk/*/dist/cjs) instead of the ESModule dist. This causes an error due to missing named exports, as Node.js can't translate the CommonJS exports to named exports and only exposes a default export.

Your environment

SDK version number

@aws-sdk/client-dynamodb@3.29.0

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

Node.js

Details of the browser/Node.js/ReactNative version

Tested on Node.js v16.8.0, v14.17.6 , v12.22.1.

Steps to reproduce

package.json:

{
  "type": "module",
  "dependencies": {
    "@aws-sdk/client-dynamodb": "^3.29.0"
  }
}

main.js:

import { DynamoDB } from "@aws-sdk/client-dynamodb";

Then run node main.js.

Observed behavior

This error occurs:

import { DynamoDB } from "@aws-sdk/client-dynamodb";
         ^^^^^^^^
SyntaxError: Named export 'DynamoDB' not found. The requested module '@aws-sdk/client-dynamodb' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from '@aws-sdk/client-dynamodb';
const { DynamoDB } = pkg;

    at ModuleJob._instantiate (internal/modules/esm/module_job.js:121:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:166:5)
    at async Loader.import (internal/modules/esm/loader.js:178:24)
    at async Object.loadESM (internal/process/esm_loader.js:68:5)

Expected behavior

The package should be imported and work using named imports, without having to use a default import.

Additional context

The error message does give a workaround, but this workaround is unergonomic and requires even more changes when migrating to ESModules. With many packages moving to being pure ESM (whether we like it or not), this problem is just adding unnecessary work when users a forced to move to ESM.

The SDK should define the exports field in the package.json instead of just main and module (which Node.js ignores). See Dual CommonJS/ES module packages. Additionally, the ESModule dist needs to add file extensions to its imports, i.e. import ... "./foo.js"; or import ... "./foo/index.js"; instead of import ... "./foo"; (doing this would probably also help with #1289).

[ghost]

Have the same issue

[maxholman]

Seems to have been caused by the update to Typescript 4.4 in 3.29 (works fine in 3.28 which was built with TS 4.3)

Excerpt from dist/cjs/index.js built with TS 4.3:

tslib_1.__exportStar(require("./DynamoDBClient"), exports);

From dist/cjs/index.js built with TS 4.4 (Note the addition of comma operator discarding the value of this):

(0, tslib_1.__exportStar)(require("./DynamoDBClient"), exports);

Wild guess is that it's an incompatibility between __exportStar and the addition of More-Compliant Indirect Calls for Imported Functions in TS 4.4 (see also microsoft/TypeScript#44624)

UPDATE: Logged a bug with TS team @ microsoft/TypeScript#45813

[trivikr]

Downgrade PRs to merge if a better solution is not available before v3.32.0 release this week:

• smithy-ts chore: downgrade typescript to ~4.3.5 smithy-lang/smithy-typescript#418
• aws-sdk-js-v3 chore(deps-dev): downgrade typescript to ~4.3.5 #2782

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.

[trivikr]

Refs: nodejs/cjs-module-lexer#63