Publish native es modules #1766
Comments
AllanZhengYP
added
the
needs-major-version
|
Thank you for your advice. It's very nice and intuitive to have this feature. However, this may need a major version update. 😉 |
|
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 |
|
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. |
|
Got it. Well I hope it comes soon 😉
…On Mon, Oct 23, 2017, 8:40 PM Jonathan Eskew ***@***.***> 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
<#1766 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABZgNKUmqdtvcP5FIC0aamq_pA5UUXXIks5svM-qgaJpZM4QAegK>
.
|
|
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. |
|
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(),
],
}; |
|
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. |
|
Well, rollup doesn't give any errors, although browser complains bundle.js:1 import { S3 } from 'aws-sdk'; |
|
see also #1769 |
|
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 |
|
@jeskew After re-reading what you wrote here:
It seems like this would be a reasonable plan moving towards this goal:
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. |
|
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 👍 |
|
Is there a plan or roadmap to move to ES modules? |
|
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! |
|
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? |
|
Are there any Now that AWS Lambda supports NodeJS 14 and also loads native JS modules (as long as import * as AWS from 'aws-sdk';That this is not possible is in fact the only reason why we have been (automatically) downgrading our entire backend to the |
|
@sebiniemann if you're using Unfortunately, since the AWS SDK is still CommonJS, there are no named exports, so doing a wildcard import means you have to use |
|
Thanks for the feedback :) We just tried this (including without
We created a basic NodeJS 14 Lambda (no layers or additional configuration) with the following minimal code (besides the package.json for module support): import AWS from 'aws-sdk';
async function handler() {
return {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!'),
};
};
export {
handler,
};// EDIT We just tried it without |
|
That error implies that something is transpiling your code or at least converting your |
|
The code was just pasted into the AWS Lambda editor. No build process involved (at least from our side). |
|
After consulting with AWS support, it was confirmed that AWS Lambda is currently not compatible with It would be possible to be compatible with both CommonJS and ECMAScript Modules by adding another |
This is we did with import * as awscjs from 'aws-sdk';
const AWS = awscjs.default;
const S3 = new AWS.S3(...Unsure if there are any pitfalls here. |
|
@ignoramous you can simplify your code to this: import AWS from 'aws-sdk';
const S3 = new AWS.S3();That works ^^ The thing that's unfortunately not currently supported is named imports: import { S3 } from 'aws-sdk';
const S3 = new S3(); |
|
Please add ESM support. Lack of ESM support is a major stumbling block in using this library, particularly with vite. If you have to do a major version upgrade, please do so. I'm getting the following error when attempting to use a dynamic import to support isomorphic javascript using vite & solid-js: Using |
+1 to this comment - does AWS not want this project to be widely adopted? this is a killer for Vite users.... |
|
The |
|
Hello, the v3 of the SDK has native ES modules. We have no plans to implement this in v2. |
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.
Having native es modules in this library would really be swell.
Thanks for your consideration.
The text was updated successfully, but these errors were encountered: