Can not build AWS-JS-SDK v3

[LeviSklaroff]

Hello,

I'm attempting to bundle a browser application that makes use of the amazon-chime-sdk-js which contains the @aws-sdk/client-chime-sdk-messaging. I've been unable to successfully bundle the application using Esbuild version 0.15.14 as it's attempting to use the non-browser version of the cjs distribution of the aws-js-sdk. The aws-js-sdk has multiple different distributions including a cjs and es version as well as browser runtimeConfigs for both. However Esbuild seems to be for some reason defaulting to cjs distribution even when --format=esm is used and doesn't seem to be using the browser distribution.

Verbose logs of finding but not using the es distribution:

"../node_modules/@aws-sdk/smithy-client"
          Attempting to load "../node_modules/@aws-sdk/smithy-client/dist-es/index.js" as a file
            Checking for file "index.js"
            Found file "index.js"
        Found main field "main" with path "./dist-cjs/index.js"
          No "browser" map found in directory "../node_modules/@aws-sdk/smithy-client"
          Attempting to load "../node_modules/@aws-sdk/smithy-client/dist-cjs/index.js" as a file
            Checking for file "index.js"
            Found file "index.js"
        Resolved to "../node_modules/@aws-sdk/smithy-client/dist-cjs/index.js" because of "require"

Error being produced:

[ERROR] Could not resolve "buffer"

    ../@aws-sdk/hash-node/dist-cjs/index.js:5:25:
      5 │ const buffer_1 = require("buffer");
        ╵                          ~~~~~~~~

  The package "buffer" wasn't found on the file system but is built into node. Are you trying to
  bundle for node? You can use "--platform=node" to do that, which will remove this error.

[evanw]

Resolved to "../node_modules/@aws-sdk/smithy-client/dist-cjs/index.js" because of "require"

This specific error message is saying that esbuild resolved something like require('@aws-sdk/smithy-client') to the CommonJS version because it was imported using require(). The ESM version might have been chosen in this case if the code had been written to use something like import '@aws-sdk/smithy-client' instead.

One of the problems here might be that the package author could be confusing ESM support with browser support. Node supports both ESM and CommonJS so when a package provides both ESM and CommonJS, the contents are expected to be the same code in different formats. It should be possible for esbuild to pick either ESM or CommonJS depending on which is more appropriate for the situation without causing any behavior changes. It's not expected that the ESM is code intended for the browser and that the CommonJS is code intended for node. Some problematic packages out there do that, but they should instead be using the browser field to provide browser-specific alternatives of node-specific code. There is more documentation about what package authors need to do to get this to work here: https://esbuild.github.io/api/#main-fields.

If you want to try to work around these problematic packages, you could try messing with esbuild's main fields setting such as specifying --main-fields=browser,module,main. This forces esbuild to prefer the module field (which typically has ESM) over the main field (which typically has CommonJS) even when there is a format mismatch (e.g. the package is loaded using CommonJS require() but you still want to load ESM). In particular, it turns off esbuild's behavior that tries to pick ESM vs. CommonJS based on how the package is imported (which is described here). Note that forcing module to come before main can break certain packages that expect require() to load a CommonJS file, which is why esbuild doesn't do this by default.

[evanw]

Closing because there was no follow-up reply and because what esbuild is doing here sounds like expected behavior to me.