Aws-sdk-js: Publish native es modules

[bennypowers]

Build steps for dev servers don't have to be a thing anymore. With native modules and relative path module specifiers, we could just run the code in the browser as-is.

import CognitoIdentityServiceProvider from '../../aws-sdk/es/clients/cognitoidentityserviceprovider';

Having native es modules in this library would really be swell.

Thanks for your consideration.

[AllanZhengYP]

Thank you for your advice. It's very nice and intuitive to have this feature. However, this may need a major version update. 😉

[bennypowers]

Pardon my ignorance of the internal workings of your library, but it seems to me that you could release a minor version that doesn't break backwards, only adds an es-module version in /dist/es/

[jeskew]

The semantics of ES modules are different enough from script-based module formats like CommonJS, UMD, and AMD that I don't think we could automate a conversion of the SDK from its current format to an ESM-based format. Since we release several times a week, if the conversion cannot be automated, then I'm not sure it's a feasible solution.

The conversion from ESM to CommonJS, however, is fairly straightforward, so if the SDK were written following ES module semantics, we could release both versions. That, however, would require a major version bump.

[bennypowers]

Got it. Well I hope it comes soon 😉

On Mon, Oct 23, 2017, 8:40 PM Jonathan Eskew [e-mail]
wrote:

The semantics of ES modules are different enough from script-based module
formats like CommonJS, UMD, and AMD that I don't think we could automate a
conversion of the SDK from its current format to an ESM-based format. Since
we release several times a week, if the conversion cannot be automated,
then I'm not sure it's a feasible solution.

The conversion from ESM to CommonJS, however, is fairly straightforward,
so if the SDK were written following ES module semantics, we could release
both versions. That, however, would require a major version bump.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aws/aws-sdk-js/issues/1766#issuecomment-338739157,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZgNKUmqdtvcP5FIC0aamq_pA5UUXXIks5svM-qgaJpZM4QAegK
.

[sholladay]

There is one tool I am aware of that takes CommonJS modules as input and outputs ES modules, which is exactly what you need to automate the conversion.

https://github.com/rollup/rollup-plugin-commonjs

That Rollup plugin is intended to be used as part of a build process to import CommonJS dependencies, but I suspect you could hack it to suit your needs relatively easily.

By the way, I disagree that offering a new type of build would demand a major version bump. It's a new feature and should not impact existing users whatsoever.

[bennypowers]

On that note, I'm experimenting with using that plugin to get the ball rolling, and actually successfully bundled using:

import sourcemaps from 'rollup-plugin-sourcemaps';
import resolve from 'rollup-plugin-node-resolve';
import builtins from 'rollup-plugin-node-builtins';
import globals from 'rollup-plugin-node-globals';
import commonjs from 'rollup-plugin-commonjs';
import json from 'rollup-plugin-json';

export default {

  input: 'src/eve-redux/eve-redux-store.js',

  output: {
    file: 'src/bundle.js',
    name: 'EVE',
    format: 'iife',
  },

  watch: {
    include: 'src/**',
  },

  plugins: [
    resolve(),
    commonjs({
      include: 'node_modules/**',
      ignoreGlobal: true,
      namedExports: {
        'node_modules/inferno-redux/index.js': ['Provider'],
        'node_modules/aws-sdk/global.js': ['util'],
      },
    }),
    sourcemaps(),
    json(),
    builtins(),
    globals(),
  ],

};

[sholladay]

Are you able to trick Rollup into converting the SDK to ES modules by doing...

format: 'es'  // instead of 'iife'

?

That might actually work! It would still be bundled, though, presumably. So I guess we'd have to then figure out a way to de-bundle it, in order to get source code to start work on a PR.

[bennypowers]

Well, rollup doesn't give any errors, although browser complains Uncaught TypeError: Failed to resolve module specifier 'aws-sdk'

bundle.js:1

import { S3 } from 'aws-sdk';

[bennypowers]

see also #1769

[sdegutis]

The AWS JS SDK having a native ESM format is especially useful for those of us who are starting to migrate away from "mandatory build phase" web development while still using "modern" libraries like React and HTM. In particular, the forward-thinking Pika tooling says that aws-sdk isn't compatible.

[sdegutis]

@jeskew After re-reading what you wrote here:

The conversion from ESM to CommonJS, however, is fairly straightforward, so if the SDK were written following ES module semantics, we could release both versions. That, however, would require a major version bump.

It seems like this would be a reasonable plan moving towards this goal:

1. Rewrite all require() calls as import statements throughout the codebase
2. Create a build script that converts the newly ESM codebase to UMD for backwards compatibility
3. Include the raw ESM codebase in new releases so that ESM-based tools can consume it.

This would involve some planning, to ensure that the code behaves the same as before, the execution of this plan happens during the course of a single day, and preparation to create or modify the relevant build tools ahead of time.

But this issue has been open for almost 2 years. I know it's probably not high priority for AWS but ES Modules are already here, the web is ready for this, and making this issue a reality instead of a dream will help projects that use ESM tooling to move forward more easily.

[juliankrispel]

This would be pretty great especially for usage with deno. I believe the change could be scripted using a tool like jscodeshift would be happy to contribute if it is something that would be considered :+1:

[antoniotorres]

Is there a plan or roadmap to move to ES modules?

[FredKSchott]

If the data helps: We're seeing more people having trouble using aws-sdk with Snowpack, Rollup, and ESM in general. Shipping native es modules would go a long way in unblocking these users!

[wperron]

I'm also interested in using this in Deno, though that would require more than simply using ESmodules syntax; imports would need to be re-written to include file extensions as well (which also means re-writing some imports to import /index.js rather than the directory name).

Any ETA available yet on this issue?